[HTTP API & REST] Организация HTTP API согласно принципам REST

[nin-jin]

Вместо псевдостатики лучше было бы использовать HARP. Клиент делает запрос вида:

?user=jin=(name;order(position;cost))

А гейтвей распаковывает его в запросы к микросервисам:

?user=jin=(name;order)
?order=12=(position;cost)
?order=34=(position;cost)
?order=56=(position;cost)

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

?user=jin=(name;order)
?order=12=34=56=(position;cost)

Ну или так, если не хочется хранить в пользователе ссылки на заказы:

?user=jin=(name)
?order(participant=jin=;position;cost)

[forgotten]

А чем лучше?

[nin-jin]

• Стандартизацией, не надо изобретать/изучать over9000 эндпоинтов и 100500 схем запросов/ответов.

• Гибкостью, схема запросов легко расширяется под разные нужды.

• Выборкой связанных ресурсов за 1 запрос вместо 1+n^k.

• Получением лишь нужных полей, а не всех подряд.

• Ну и другими плюшками типа фильтраций, сортировок, агрегаций и тд.

[forgotten]

А какие недостатки этого подхода?

[nin-jin]

Основной недостаток - необычность подхода со всеми вытекающими.

[forgotten]

Надо же, какая идеальная технология!

Но я пожалуй подожду её более широкого внедрения. Вдруг там всё-таки есть недостатки.

[nin-jin]

Ну вот с таким подходим вы и дождались повсеместного внедрения GQL с кучей косяков на фундаментальном уровне.

[forgotten]

С кучей известных косяков.

[nin-jin]

Известных неисправимых косяков, да.

[xmdy]

А можете поделиться списком этих известных неисправимых косяков или статьями на них?

[nin-jin]

Там выше в статье всё есть.

[breninsul]

гусеничный велосипед.

[Senyaak]

Не могу понять, каким способом можно позволить клиенту отвечать за user_id ?

[forgotten]

1. Возвращать user_id из эндпойнта регистрации / проверки логина и пароля [которого на схеме нет, но сделать его, очевидно, придётся]

2. Требовать передачу user_id во все остальные эндпойнты [на самом деле, во все релевантные эндпойнты]

[Senyaak]

Всёравно придётся совершать проверку переданного user_id в сервисе D, получаются какието костыли и ненужная нагрузга логики всей архетектуры. Поэтому мне не понятно как можно позволить клиенту отвечать за user_id

[forgotten]

Так же, как можно позволить клиенту отвечать за токен.

[LaRN]

• если сервис C отвечает статусом 304 Not Modified, вернуть данные из кэша;

А в чем преимущество такого подхода?

Ведь чтобы понять что ничего не поменялось, нужно дёрнуть сервис.

Ну и проще отдать ответ сервиса, чем с кешем что-то делать.

[forgotten]

Если профиль композитный, т.е. сервису B нужно самому выполнить несколько обращений для формирования ответа, то профит есть. Если там 20 байт JSON-а, то разница малозаметна, конечно.