Этот подход, на самом деле, описывает такой чуть более REST-овый GraphQL: есть один эндпойнт, который умеет всё (только, отличие от GraphQL, с кэшированием по id). Проблемы те же:
Нельзя понять, что за операция была запрошена (надо тело читать). Отсюда такой сервис сложно профилировать (какие конкретно операции «тяжёлые») и ещё сложнее поставить рейтлимитер
Содержимое GET /api/search/{id}нетипизировано — невозможно узнать, что находится внутри (какие данные каких типов), пока не прочитаешь.
Я бы не был столь категоричен. Возможны разные варианты. Ключевой момент — клиент получает от сервера представление для рендеринга, а не семантичные данные. В случае MMORPG это, как правило, не так.
Ну, в теории да, на практике нет. Скажем, Google свой веб-API карт называет Google Maps API, ArcGIS — Maps SDK, а Майкрософт свой поначалу называл Bing Maps SDK, а потом переименовал и вовсе в Web Control. Кто во что горазд, короче.
Да, он вполне возможен с точки зрения архитектуры (хотя не совсем REST-way с той точки зрения, что id — черный ящик, по нему невозможно понять, что это была за операция).
Действия сторонних акторов не участвуют в определении идемпотентности. Предполагаете, что между последовательными запросами никакой другой актор состояние не модифицирует.
Если профиль композитный, т.е. сервису B нужно самому выполнить несколько обращений для формирования ответа, то профит есть. Если там 20 байт JSON-а, то разница малозаметна, конечно.
Каким образом? Объём данных не изменился, его всё равно надо как-то синхронизировать (хотя бы на холодном старте). Ну и в обсуждаемом кейсе типа синхронизации заказов объём данных настолько незначителен, что всерьёз обсуждать какие-то выигрыши в плане трафика несерьёзно.
Можно. Тем не менее, хранить один токен, который меняется редко и целиком, гораздо проще, чем синхронизировать БД (в плане сложности кода)
Кому? Серверу? Откуда?
Там в разделе “Disadvantages of row-based replication” достаточно хорошо описано, в чём сложность.
Вы серьёзно пытаетесь убедить, что stateful клиент с синхронизацией через БД лучше, чем stateless с синхронизацией через API? Синхронизация через БД вообще антипаттерн, и оправдана в крайне редких кейсах.
Ну, уже снова 0.
Только сейчас заметил комментарий ¯\_(ツ)_/¯
Этот подход, на самом деле, описывает такой чуть более REST-овый GraphQL: есть один эндпойнт, который умеет всё (только, отличие от GraphQL, с кэшированием по id). Проблемы те же:
Нельзя понять, что за операция была запрошена (надо тело читать). Отсюда такой сервис сложно профилировать (какие конкретно операции «тяжёлые») и ещё сложнее поставить рейтлимитер
Содержимое
GET /api/search/{id}
нетипизировано — невозможно узнать, что находится внутри (какие данные каких типов), пока не прочитаешь.Я видел множество попыток. И да, получается аналог HTML
`<div>Hello, TrueRomanus</div>` — представление для рендеринга
{ "user_name": "TrueRomanus" } — семантические данные
Я бы не был столь категоричен. Возможны разные варианты. Ключевой момент — клиент получает от сервера представление для рендеринга, а не семантичные данные. В случае MMORPG это, как правило, не так.
Нет. GeForce now — скорее да, и то с некоторой натяжкой. MMORPG всё-таки позволяют кнопки в меню нажимать локальным кодом, а не вызовом сервера.
Не вижу особой разницы между этими утверждениями
Ну такое. Вот Amazon SDK for JavaScript https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/welcome.html
А вот, скажем, Ethereum JavaScript API: https://web3js.readthedocs.io/en/v1.10.0/getting-started.html
Казалось бы, найди 5 отличий в том, как их надо подключать.
Ну, в теории да, на практике нет. Скажем, Google свой веб-API карт называет Google Maps API, ArcGIS — Maps SDK, а Майкрософт свой поначалу называл Bing Maps SDK, а потом переименовал и вовсе в Web Control. Кто во что горазд, короче.
Это следующая глава ;)
Этот паттерн я разбирал в главе «Асинхронность и управление временем»
https://habr.com/ru/articles/732646/
Да, он вполне возможен с точки зрения архитектуры (хотя не совсем REST-way с той точки зрения, что id — черный ящик, по нему невозможно понять, что это была за операция).
Полагаю, вас интересует не идемпотентность, а транзитивность.
Раскрыто (частично) в другой главе: https://habr.com/ru/articles/737728/
Действия сторонних акторов не участвуют в определении идемпотентности. Предполагаете, что между последовательными запросами никакой другой актор состояние не модифицирует.
Если профиль композитный, т.е. сервису B нужно самому выполнить несколько обращений для формирования ответа, то профит есть. Если там 20 байт JSON-а, то разница малозаметна, конечно.
Так же, как можно позволить клиенту отвечать за токен.
Возвращать
user_id
из эндпойнта регистрации / проверки логина и пароля [которого на схеме нет, но сделать его, очевидно, придётся]Требовать передачу
user_id
во все остальные эндпойнты [на самом деле, во все релевантные эндпойнты]Каким образом? Объём данных не изменился, его всё равно надо как-то синхронизировать (хотя бы на холодном старте). Ну и в обсуждаемом кейсе типа синхронизации заказов объём данных настолько незначителен, что всерьёз обсуждать какие-то выигрыши в плане трафика несерьёзно.
Можно. Тем не менее, хранить один токен, который меняется редко и целиком, гораздо проще, чем синхронизировать БД (в плане сложности кода)
Кому? Серверу? Откуда?
Там в разделе “Disadvantages of row-based replication” достаточно хорошо описано, в чём сложность.
Вы серьёзно пытаетесь убедить, что stateful клиент с синхронизацией через БД лучше, чем stateless с синхронизацией через API? Синхронизация через БД вообще антипаттерн, и оправдана в крайне редких кейсах.
С кучей известных косяков.
Надо же, какая идеальная технология!
Но я пожалуй подожду её более широкого внедрения. Вдруг там всё-таки есть недостатки.
А какие недостатки этого подхода?
А чем лучше?