GK
Есть много разных подходов.
От отдельных сервисов для отчетов и до разных стратегий сборки данных на bff.
Size: a a a
2021 May 05
p
А его нет :) Это иллюстрация тезиса :)
AL
Ну и соответсвенно в этом "устаканивании" участвуют как локальные, так и забугорные клановые группы.
AS
Ответ на пост от марта 2018? Back to the future?
PD
Это далеко не единственный и далеко не самый оптимальный подход )
p
Фигачить всё POST'ом? )
GK
Понял, сорри)
PD
Ну да, REST maturity level 1
PD
Для того же финтеха это вообще оптимальный подход. Да и для прочих сложных задач, где лучше RPC, нежели REST-как-концепция (которая вообще ужасна)
p
Только выбрать сериализацию + схему
PD
Если язык единый, то да.
Если нет, то OpenApi вполне покрывает такой подход.
Если нет, то OpenApi вполне покрывает такой подход.
p
Каноничный rest ужасен при операциях над группами сущностей или когда надо что-то вроде транзакции сделать
PD
А еще он не совместим с PCI DSS, ФЗ 152 и GDPR (т.е. некоторые поисковые запросы принципиально нельзя делать через GET)
И сложный поиск в нем ужасен.
Ну и так далее.
Я потому сразу рисую свою схему на POSTах, добавляя GET там, где есть смысл в кэшировании на уровне сети.
И сложный поиск в нем ужасен.
Ну и так далее.
Я потому сразу рисую свою схему на POSTах, добавляя GET там, где есть смысл в кэшировании на уровне сети.
p
Как кешить если tls?
PD
Так оно может быть кэшироваться на стороне клиента, я же не знаю, как там TLS терминируется и что там стоит еще.
Но, в среднем, толку от этого мало, конечно (кроме картинок)
Но, в среднем, толку от этого мало, конечно (кроме картинок)
GK
Ну REST (L2) - это CRUD поверх HTTP. Если нужно что-то большее, чем CRUD, то REST не подходит.
PD
Но иногда это очень сложно объяснить клиентам. Вплоть до реализации Rest (L2) поверх нормального REST (L1) для конкретного внедрения
VI
Принес вам третью часть оценок https://vvsevolodovich.dev/how-to-estimate-software-projects-chapter-3-costs-resources/
PD
Дочитал серию. Но подобная схема не работает вообще никогда.