Pull to refresh
375
0

Разрабатываю API более 10 лет

Send message

Только сейчас заметил комментарий ¯\_(ツ)_/¯

Этот подход, на самом деле, описывает такой чуть более REST-овый GraphQL: есть один эндпойнт, который умеет всё (только, отличие от GraphQL, с кэшированием по id). Проблемы те же:

  1. Нельзя понять, что за операция была запрошена (надо тело читать). Отсюда такой сервис сложно профилировать (какие конкретно операции «тяжёлые») и ещё сложнее поставить рейтлимитер

  2. Содержимое GET /api/search/{id}нетипизировано — невозможно узнать, что находится внутри (какие данные каких типов), пока не прочитаешь.

Я видел множество попыток. И да, получается аналог HTML

`<div>Hello, TrueRomanus</div>` — представление для рендеринга
{ "user_name": "TrueRomanus" } — семантические данные

Я бы не был столь категоричен. Возможны разные варианты. Ключевой момент — клиент получает от сервера представление для рендеринга, а не семантичные данные. В случае MMORPG это, как правило, не так.

например бутстрапер любой 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-а, то разница малозаметна, конечно.

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

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

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

  1. Каким образом? Объём данных не изменился, его всё равно надо как-то синхронизировать (хотя бы на холодном старте). Ну и в обсуждаемом кейсе типа синхронизации заказов объём данных настолько незначителен, что всерьёз обсуждать какие-то выигрыши в плане трафика несерьёзно.

  2. Можно. Тем не менее, хранить один токен, который меняется редко и целиком, гораздо проще, чем синхронизировать БД (в плане сложности кода)

  3. Кому? Серверу? Откуда?

  4. Там в разделе “Disadvantages of row-based replication” достаточно хорошо описано, в чём сложность.

Вы серьёзно пытаетесь убедить, что stateful клиент с синхронизацией через БД лучше, чем stateless с синхронизацией через API? Синхронизация через БД вообще антипаттерн, и оправдана в крайне редких кейсах.

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

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

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

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

Information

Rating
Does not participate
Location
Россия
Registered
Activity