Нет, совершенно не о REST API, хотя ему (а также сравнению с gRPC и GraphQL) посвящен отдельный раздел. Напротив, я старался сделать книгу максимально абстрагированной от конкретных технологий.
Этот подход, на самом деле, описывает такой чуть более 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-а, то разница малозаметна, конечно.
На русском в настоящий момент нет. Но можно почитать гитхаб.
На английском — amazon, apple books.
Надеюсь, окажется полезной :)
Пон-дю-Гар
Спасибо!
Спасибо за совет, добавил!
Нет, совершенно не о REST API, хотя ему (а также сравнению с gRPC и GraphQL) посвящен отдельный раздел. Напротив, я старался сделать книгу максимально абстрагированной от конкретных технологий.
Ну, уже снова 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во все остальные эндпойнты [на самом деле, во все релевантные эндпойнты]