АС
о чем я и говорю
это не стандарт, а говно
потому что позволяет кривотолки
это не стандарт, а говно
потому что позволяет кривотолки
Size: a a a
2021 November 03
АС
вот уже начался холивар по поводу методов
AB
Если норм структурировано, то пофиг. Я как то сгенерил клиент для JetBrains UpSource по их html докам. Там таблички, ссылки на типы используемые в апи, урлы и т.д. И по сути генерация работала так же хорошо, как и по open api json'у бы генерил. Но это всё не от хорошей жизни было, конечно же. Просто парсить и генерить было быстрее, чем руками копипастить.
PD
Там скорее идея в том, что бывают только сущности и CRUD поверх и ничего больше.
Это не очень сочетается с реальной жизнью
Это не очень сочетается с реальной жизнью
АС
разумеется
вообще не согласуется
вообще не согласуется
PD
Но есть куча людей, выросших из RoR или Django, которые считают, что это и есть единственно правильный способ Domain Design (
AB
Или те, кто ничего другого не видел)
AS
вот вот а потом начинается. а давай те в теле будем передавать команду....
AB
А сложнее апи чем пользовательские данные из пяти полей одной сущности погонять для post/put тоже не делали. Там регулярно успешный успех в апи.
VF
Тоже так делаю, нравится
AB
Плохо штоль. Зато всё в теле. Не айди в пути типа /api/users/{id} и в теле данные, как будто в этом был великий смысл для всех сторон - один писал апи которое айди берет из пути, другой писал клиент, который данные размазывает в путь и в тело.
PD
Это ты еще rest-овый специальный отдельный язык запросов для GET вспомни )
AS
ну не ВСЕ в теле это не комильфо... комильфо это часть в URL, часть в параметрах URL, команду в методе, а уточнение команды в теле& причем обязательно ссылка на предыдущее состояние на сервере да - вот тогда у вас будет прям феншуйный феншуй современного REST приложения
AB
Меня какое то время назад впечатляли в одном АПИ запросы на изменение данных пользователя через метод пост с передачей данных в query string. И я чеснгря хотел бы забыть об этом, всякие json и т.д. в query string - тоже неплохо.
PD
А зачем что-то, кроме entrypoint - убирать в URL?
И зачем команды кроме POST и, редко-редко, GET (для статических ресурсов)?
И зачем команды кроме POST и, редко-редко, GET (для статических ресурсов)?
PD
Т.е. феншуйный феншуй - но в результате ужасный нечитаемый код и на клиенте и на сервере
DK
И зачем коды ответов, кроме 200, для всех реально обработанных запросов - не отвалившихся "по пути"...
PD
Ну, еще бывают ошибки авторизации и вот у меня отдельно "нужно подтверждение операции".
Ну и ошибки тоже бывают двух типов "можно повторять", "нет смысла повторять".
Ну и ошибки тоже бывают двух типов "можно повторять", "нет смысла повторять".
VF
Это как параметры запихивать в имя функции и потом оттуда доставать
PD
Просто ошибки и http words - это про транспорт и там нужно оставлять транспортные вещи, а не бизнесовые.