ну на расте и хаскеле как раз таки пишут) их ругают за другие вещи)

хз) когда довелось писать на расте - язык крутой, экосистемы нету) так что хз что там пишут

тут такой момент) ты может и не пользовался, а вот другие в команде могут и это пиздец

Благо в моей власти сие пресечь)

но поднять блокчейн на расте это да) за милую душу)

хз) когда довелось писать на расте - язык крутой, экосистемы нету) так что хз что там пишут

как так нет экосистемы? в каком плане?

она молодая очень но все там есть

ну в плане стороних пакетов) как-то маловато, большая часть в версия 0.0.x и непонятно развиваются или нет)

но язык хорош, после пхп особенно

хз, я иногда брожу по гитхабу в поисках интересных php-ных либ и больше грущу. А на расте видел уже с десяток интересных проектов. По поводу того что они все 0.0.x - ну да... с другой стороны найди мне на php либу такого уровня: https://github.com/diesel-rs/diesel

я больше напрягался когда приходилось допиливать либы на расте, чем искать омр под пыху)

Всем привет. Скажите, есть ли аналог аргумент резолвера симфонийского для ответов? То есть чтобы респонсы определенного типа ловить, на их основе генерировать другие и отдавать. Простите, если это общеизвестно, а я плохо гуглю, ткните меня туда :)

Скажи для начала чем тебе симфоневский не угодил

Скажи для начала чем тебе симфоневский не угодил

Угодил. Я хочу не для реквеста, а для респонса. Пока нашел только вариант слушать ивент и там проверять тип респонса.

Всем привет. Скажите, есть ли аналог аргумент резолвера симфонийского для ответов? То есть чтобы респонсы определенного типа ловить, на их основе генерировать другие и отдавать. Простите, если это общеизвестно, а я плохо гуглю, ткните меня туда :)

к примеру есть старый и нерекомендуемый TemplateListener, который берет массив, возвращаемый из экшна и рендерит темплейт, который указан в аннотации\конфиге экшна, с этими данными.

А, неправильно прочитал

хз, я иногда брожу по гитхабу в поисках интересных php-ных либ и больше грущу. А на расте видел уже с десяток интересных проектов. По поводу того что они все 0.0.x - ну да... с другой стороны найди мне на php либу такого уровня: https://github.com/diesel-rs/diesel

doctrine

Всем привет. Скажите, есть ли аналог аргумент резолвера симфонийского для ответов? То есть чтобы респонсы определенного типа ловить, на их основе генерировать другие и отдавать. Простите, если это общеизвестно, а я плохо гуглю, ткните меня туда :)

у симфони есть kernel.view ивент, а реализовать что-то похожее на аргумент ресолверы в целом не составляет проблем

к примеру есть старый и нерекомендуемый TemplateListener, который берет массив, возвращаемый из экшна и рендерит темплейт, который указан в аннотации\конфиге экшна, с этими данными.

Если старый и не рекомендуемый, то не подходит. :)

doctrine

там куча говнокода

у симфони есть kernel.view ивент, а реализовать что-то похожее на аргумент ресолверы в целом не составляет проблем

А насколько это хорошая практика? Ловить там все респонсы определенного типа и вместо них делать другие.

А насколько это хорошая практика? Ловить там все респонсы определенного типа и вместо них делать другие.

ну я так делаю. я возвращаю какие-то штуки и дальше смотрю - если это респонс - не трогаю. Если это DTO - кидаю в сериалайзер. Могу сделать что-то типа если это указание слепить какой-то респонс - попросить какой-то сервис слепить этот респонс (а там типа изи сделать через теги)

у меня есть контроллеры которые ничего про реквест или респонс не знают - все вынесено на уровень выше

ну я так делаю. я возвращаю какие-то штуки и дальше смотрю - если это респонс - не трогаю. Если это DTO - кидаю в сериалайзер. Могу сделать что-то типа если это указание слепить какой-то респонс - попросить какой-то сервис слепить этот респонс (а там типа изи сделать через теги)

Вот такие мысли и были примерно, да. Спасибо!

Если старый и не рекомендуемый, то не подходит. :)

это пример. Конкретно этот листнер не рекомендовалось использовать потому что он добавляет +30мс к времени ответа, но можно там подсмотреть kernel.view.

у меня есть контроллеры которые ничего про реквест или респонс не знают - все вынесено на уровень выше

И что остаётся в контроллерах тогда? У тебя графкюл?

И что остаётся в контроллерах тогда? У тебя графкюл?

Оркестрация)

Graphql пока нет (оч медленно пытаюсь прикрутить) но разница как бы... Ее нет особо

Не ну просто был бы graphql тогда понятно что контроллерам не обязательно знать про реквест/респонс так как они то ничего особо не решали, а обычный рест тогда непонятно почему контроллер не знает что и в каком виде он отдаёт

не вижу преимуществ писать return $someDto; и обрабатывать это в лисенере вместо условно return $someDataMapper->toJson($dto);

не вижу преимуществ писать return $someDto; и обрабатывать это в лисенере вместо условно return $someDataMapper->toJson($dto);

ну не видешь - и ладно)

а я не вижу разницы между "выплевывать json в контексте http api и выплевывать json в контексте graphql"))

Ну с graphql может быть удобно собирать ответ в лисенерах, я просто думал о такой штуке что бы генерить например класс Schema и что бы он имплементил интерфейсы там например PostsInterface, PostAuthorInterface ну и там методы нужные, к примеру postsOffset postsLimit postsSerializationStrategy, а в лисенерах уже смотреть на этот класс и его интерфейсы, и соответственно формировать респонс, но это наркомания

в том варианте который ты описал (в силу того что я плохо понял как это будет работать) - наркомания. А так процесс сборки респонса никак не отличается, graphql у тебя, json по http или что-то еще

короч, ладно. Я не готов сегодня что-то на эту тему вещать.

Всем привет. Вчера говорили о возвращении из контроллера DTO и последующей обработки в листенере. Скажи, пожалуйста, как ты заставляешь симфони не ругаться на то, что контроллер не возвращает респонс?

Всем привет. Вчера говорили о возвращении из контроллера DTO и последующей обработки в листенере. Скажи, пожалуйста, как ты заставляешь симфони не ругаться на то, что контроллер не возвращает респонс?

ивент листенер я, конечно, не проверял, но там наверняка не тайпхинт

Я понимаю, да. Только вот при попытке вернуть что-то отличное от респонса из контроллера будет ошибка The controller must return a response.

ну а откуда идёт эта ошибка, по - твоему?

Не, ты можешь вернуть что угодно, но в конечном результате должен привести в листерерах это к Response который ожидает симфони

её наверняка отдаёт другой слушатель если повесишь свой с приоритетом выше и сделаешь в нем Response - все будет ок

ну а откуда идёт эта ошибка, по - твоему?

Я полагал что кернел контролирует прежде чем отдать в листенер.

Окей. Спасибо, будем попробовать.

я думаю, что если и контролирует, то после листенеров но не проверял

Ох, надо было не на kernel.response а на kernel.view вешать лисенер, насколько я понимаю.

Ох, надо было не на kernel.response а на kernel.view вешать лисенер, насколько я понимаю.

Да

Ага. Спасибо. Еще не до конца понял, могу ли как-то в конкретных трансформерах добиться тайпхинтинга. Как ты решаешь это проблему?

Плачу, и не решаю

Это нельзя без дженериков решить

Досадно.

Коллеги! никто не сталкивался с проблемой дебага в phpstorm? шторм подхватывает сессию икс-дебага, но при любом шаге просто останавливает сессию.. в браузере пусто

Может какой fatal. Смотри все логи. Сам пых может падать если баг в иксдебаг

в конфигах и само окружение не менялось, логи пустые... Видимо система собирается помереть.. и необходима переустановка

Вопрос, клиенту нужно отдавать профиль юзера и только текущего, чужие профили клиенту не нужны. эндпоинт с доступом по токену в котором айди юзера в пейлоде, хочу сделать просто /profile и отдавать нужный профиль в зависимости от того кто шлет запрос, но это не по понятиям реста?

Не хочу делать колбасу из /user/{id}/profile и т.д.

Вопрос, клиенту нужно отдавать профиль юзера и только текущего, чужие профили клиенту не нужны. эндпоинт с доступом по токену в котором айди юзера в пейлоде, хочу сделать просто /profile и отдавать нужный профиль в зависимости от того кто шлет запрос, но это не по понятиям реста?

нет понятий реста

Не хочу делать колбасу из /user/{id}/profile и т.д.

Читай про HATEOAS, например про HAL JSON. Поможет избавиться от вложенных ресурсов и подскажет как красиво делать перелинковку ресурсов

Ну тут как минимум один и тот же урл отдает разные ресурсы

Читай про HATEOAS, например про HAL JSON. Поможет избавиться от вложенных ресурсов и подскажет как красиво делать перелинковку ресурсов

а через год ты разачаруешься и вернешься к RPC

потому что осознаешь что все эти HATEAS работают только для гипертекста

Это будет потом, а сейчас я как раз с rpc пытаюсь слезть))

Вопрос, клиенту нужно отдавать профиль юзера и только текущего, чужие профили клиенту не нужны. эндпоинт с доступом по токену в котором айди юзера в пейлоде, хочу сделать просто /profile и отдавать нужный профиль в зависимости от того кто шлет запрос, но это не по понятиям реста?

с рестом тут два момента: 1. делая подобное ты делаешь невозможным использование http кэша (уверен тебе тут насрать) 2. делая подобное ты заставляешь клиент хардкодить ссылки (от чего ты не уйдешь никак и никакие HATEOAS тебе тут не помогут)

Да, hateoas тоже не понял чем тут поможет, про кеш знаю, действительно не нужен, но прям коробит что один url уже не будет однозначно идентифицировать один ресурс

ну то есть как. можно сделать полное self discovery урлов но это не сильно помогает в условиях мобильных приложений и структуры данных те же тебе всеравно придется хардкодить, а это невилирует любой профит от всех этих загонов. А потому повторюсь - HATEOAS работает только и только в условиях гипертекста, когда данные и метаданные помогают клиенту интерпритировать контет (+ code on demand для ситуаций когда не может)

тогда у тебя полная инкапсуляция на сервере и все круто и красиво. И единственная хрень которая так работает - браузер

и то люди сча SPA почему-то пишут (потоу что web сломан))

Есть ли какие-то бест-практис гайды по созданию REST API. Книжка Стирджеона норм? https://leanpub.com/build-apis-you-wont-hate

Норм, читал недавно

ERROR: S client not available

Есть ли какие-то бест-практис гайды по созданию REST API. Книжка Стирджеона норм? https://leanpub.com/build-apis-you-wont-hate

те же принципы по которым проектируешь любое API. не только http

тебе должно быть удобно пользоваться этой апишкой

а для этого ты должен понимать как апишкой будут пользоваться) потому сейчас модны всякие graphql потому что они позволяют делигировать часть ответственности на клиент))

Ну вот и я из соображений удобства, клиенту нужен просто один профиль того кто авторизован, нет необходимости его вобще как-то идентифицировать

а через год ты разачаруешься и вернешься к RPC

Не знаю, мы уже полтора года в команде HAL практикуем, пока проблем не встречали. И фронденщики с мобильщиками довольны

Ну вот и я из соображений удобства, клиенту нужен просто один профиль того кто авторизован, нет необходимости его вобще как-то идентифицировать

там будет больше трабла с отслеживанием изменений структур данных. Во всяком случае если у тебя схема сильно меняется

Не знаю, мы уже полтора года в команде HAL практикуем, пока проблем не встречали. И фронденщики с мобильщиками довольны

мне было бы любопытно узнать за счет чего они довольны (за счет HAL или за счет того что предсказуемая апишка? мне больше кажется второе и сам по себе HATEOAS тут не причем, но он косвенно помогает тебе добиться ценных качества вроде дока, схема, предсказуемость, консистентность)

Мм не уверен что понял, если меняется схема это уже вопрос версионирования, как это зависит от того под одним или разными урлами сидят однотипные ресурсы или нет?

но это надо вникать, разбираться... мой опыт подсказыавает что достаточно просто иметь: - консистентную схему - то есть всегда одинаково хэндлить на уровне схемы списки, детали и т.д. что бы это было расширяемо и предсказуемо - документацию - насколько легко следить за актуальностью доки и следить за обратной совместимостью

и есть куча способов этого добиться, но говорить что HATEOAS all the things это глупо

и да, даже с HATEOAS это всеравно будет RPC)

Вот это кстати аргумент, чисто ради консистентонсти не делать эндпоинтов которые идентифицируют ресурсы по разному

Мм не уверен что понял, если меняется схема это уже вопрос версионирования, как это зависит от того под одним или разными урлами сидят однотипные ресурсы или нет?

ну типа описать схему респонса можешь?

полностью

Могу, на все реквесты и респонсы есть json-schema об которую апи сама себя валидирует

норм

И дока с той же схемы

Ладно, не буду городить, пусть будет чуть менее удобно но более предсказуемо, спасибо за ваше мнение

А подскажите с решением такого кэйса: есть endpoint /documents, например, для роли employer он имеет усеченный набор параметров, для роли manager более полный. Как документировать такое в swagger?

опциональные параметры?

А подскажите с решением такого кэйса: есть endpoint /documents, например, для роли employer он имеет усеченный набор параметров, для роли manager более полный. Как документировать такое в swagger?

oneOf

Хотя swagger ui, насколько я знаю, до сих пор не научился рендерить oneOf и anyOf

Та же фигня у api blueprint, схему умеет генерить с oneof а пример в доке пустой делает

Напоролся на это когда хотел показать секцию included у json-api

Но там хотя бы можно описать без one of, просто массив и какого типа в нем могут быть обьекты, тогда будет все ок в доке но наоборот пустая json-schema

Нашел еще такое решение, у инстаграмма, /users/self отдает всегда свой профиль по аксес токену

Не такая уж бредовая идея получается

Gmail - /users/me

Тоже юзаю /users/me но только для тестов, типа что бы получить текущего юзера по токену (/users/me?apiToken=...) потому что при каждом тесте у моего фикстурного юзера разный ид и это очень удобно, но на проде нет смысла юзать этот ендпоинт, всё равно фронт знает ид своего пользователя если он аутентифицирован

кто в логсташ логирует?

кто в логсташ логирует?

Есть немного

он локально (относительно кода) стоит и фигачит в удаленный эластик или рядом с эластиком его поставили и фигачите в него из кода по IP?