Каким образом? Объём данных не изменился, его всё равно надо как-то синхронизировать (хотя бы на холодном старте). Ну и в обсуждаемом кейсе типа синхронизации заказов объём данных настолько незначителен, что всерьёз обсуждать какие-то выигрыши в плане трафика несерьёзно.
Можно. Тем не менее, хранить один токен, который меняется редко и целиком, гораздо проще, чем синхронизировать БД (в плане сложности кода)
Кому? Серверу? Откуда?
Там в разделе “Disadvantages of row-based replication” достаточно хорошо описано, в чём сложность.
Вы серьёзно пытаетесь убедить, что stateful клиент с синхронизацией через БД лучше, чем stateless с синхронизацией через API? Синхронизация через БД вообще антипаттерн, и оправдана в крайне редких кейсах.
но не указали, что там перед хостом может быть еще и userinfo
Указал: «помимо указанных компонентов в стандарте перечислены разнообразные исторические наслоения (например, передача логинов и паролей в URL или использование не-UTF кодировки), которые нам в рамках вопросов дизайна API неинтересны.»
Ну и ссылка на RFC 3986, имхо, так же могла бы быть уместной.
URI как концепция отдельно от URL не очень интересен в рамках дизайна API. Но да, будет не лишней, добавлю. Спасибо.
Ну и, в целом, понятно почему. Потому что читается это вот так:
тело сообщения НЕ ДОЛЖНО включаться в в запрос, если спецификация метода НЕ РАЗРЕШАЕТ. Не «запрещает», а именно «не разрешает»
В спецификации метода GET нет РАЗРЕШЕНИЯ на посылку тела (как и, скажем, в описании CONNECT, DELETE и HEAD — нигде не сказано, что тела у этих методов нет; а вот в описании PUT, POST и OPTIONS прямым текстом такое РАЗРЕШЕНИЕ есть) — что как раз трактуется согласно параграфу 4.3 как запрет иметь body. Очевидно, это плохие формулировки, и запретить тело GET-запросам следовало явно (как это почему-то было сделано для метода TRACE). Но имеем что имеем — в последующих RFC формулировку смягчили до SHOULD NOT и описали зоопарк реализаций.
В стандарте написано ровно то же, что и я написал ;)
Although request message framing is independent of the method used, content received in a GET request has no generally defined semantics [...] A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported. An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain.
Что касается передачи доп. параметров в немодицифицирующем запросе, то для этого разрабатывают новый метод QUERY (хотя в целом никто не запрещал использовать для этой цели SEARCH). Будет разобрано в следующей главе.
Это фактически один из кастомных форматов для описания списков изменений. В целом можно и так, хотя это плохо расширяется если нужно, например, удалять элементы массивов.
Во-первых, это достаточно сложный паттерн чтобы предлагать его имплементировать клиентам публичного API. Предоставить компонент для записи в локальные БД для каждой платформы не выглядит простой задачей, ну и вообще на разработчика API налагает много дополнительной ответственности.
Во-вторых, запись в локальную БД может быть неудачной или локальная БД может быть повреждена/стёрта.
Во-третьих, паттерн «клиент передаёт на сервер известный ему заказ» вообще чрезвычайно опасен. Сервер обязан дополнительно валидировать, что клиент не врёт и заказ действительно вот такой. Зачем тогда передавать сам заказ, достаточно его идентификатора.
Самое главное, я не вижу, каким образом это проще. Подмена синхронизации через API [у которого есть формальные интерфейсы и спецификация] синхронизацией через БД [у которой в лучшем случае есть документированная схема] почти всегда плохая идея даже если речь идёт о внутренних системах.
Если пользователи и так имеют доступ к системе под своим логином — то, грубо говоря, да. Разрешить пользователю на спец. странице получить токен для API [не обязательно хранить его в базе, можно и stateless], и с этим токеном они смогут делать автоматические запросы.
Статистически, для гарантированного развития алкогольной болезни печени мужчинам надо употреблять около 70 г чистого этанола в день в течение 8 лет, в то время как женщинам — всего 20 г. Это примерно 150 мл водки, либо 500 мл сухого вина или 1000 мл пива.
По ссылке написано прямо обратное
При злоупотреблении спиртными напитками в гепатотоксичных дозах далеко зашедшие стадии АБП (выраженный фиброз и цирроз печени) формируются лишь у 10 - 20% пациентов [2,3], что отражает влияние ряда других факторов (генетических, стиля приема алкоголя и т.д.) на прогрессирование поражения печени
Каким образом? Объём данных не изменился, его всё равно надо как-то синхронизировать (хотя бы на холодном старте). Ну и в обсуждаемом кейсе типа синхронизации заказов объём данных настолько незначителен, что всерьёз обсуждать какие-то выигрыши в плане трафика несерьёзно.
Можно. Тем не менее, хранить один токен, который меняется редко и целиком, гораздо проще, чем синхронизировать БД (в плане сложности кода)
Кому? Серверу? Откуда?
Там в разделе “Disadvantages of row-based replication” достаточно хорошо описано, в чём сложность.
Вы серьёзно пытаетесь убедить, что stateful клиент с синхронизацией через БД лучше, чем stateless с синхронизацией через API? Синхронизация через БД вообще антипаттерн, и оправдана в крайне редких кейсах.
С кучей известных косяков.
Надо же, какая идеальная технология!
Но я пожалуй подожду её более широкого внедрения. Вдруг там всё-таки есть недостатки.
А какие недостатки этого подхода?
А чем лучше?
Это и есть чистый сокет.
Я думаю количество реальных систем, использующих JSON-RPC на чистых сокетах, вряд ли превышает количество пальцев на моей левой руке.
Возможно, переставлю абзац выше, спасибо.
Указал: «помимо указанных компонентов в стандарте перечислены разнообразные
исторические наслоения (например, передача логинов и паролей в URL или
использование не-UTF кодировки), которые нам в рамках вопросов
дизайна API неинтересны.»
URI как концепция отдельно от URL не очень интересен в рамках дизайна API. Но да, будет не лишней, добавлю. Спасибо.
…что неприменимо к публичным HTTP API да и к REST как методологии (реализации клиента и сервера должны быть независимы)
Ну и, в целом, понятно почему. Потому что читается это вот так:
тело сообщения НЕ ДОЛЖНО включаться в в запрос, если спецификация метода НЕ РАЗРЕШАЕТ. Не «запрещает», а именно «не разрешает»
В спецификации метода GET нет РАЗРЕШЕНИЯ на посылку тела (как и, скажем, в описании CONNECT, DELETE и HEAD — нигде не сказано, что тела у этих методов нет; а вот в описании PUT, POST и OPTIONS прямым текстом такое РАЗРЕШЕНИЕ есть) — что как раз трактуется согласно параграфу 4.3 как запрет иметь body. Очевидно, это плохие формулировки, и запретить тело GET-запросам следовало явно (как это почему-то было сделано для метода TRACE). Но имеем что имеем — в последующих RFC формулировку смягчили до SHOULD NOT и описали зоопарк реализаций.
Ссылка на стандарт есть в тексте статьи. RFC 9110 заменил и 2616, и 723*.
В стандарте написано ровно то же, что и я написал ;)
Что касается передачи доп. параметров в немодицифицирующем запросе, то для этого разрабатывают новый метод QUERY (хотя в целом никто не запрещал использовать для этой цели SEARCH). Будет разобрано в следующей главе.
Но, наверное, best practice из gRPC (и тогда уж GraphQL) стоит добавить, согласен
Это фактически один из кастомных форматов для описания списков изменений. В целом можно и так, хотя это плохо расширяется если нужно, например, удалять элементы массивов.
poll — опрашивать ;)
Можно и pull, но polling кмк более общепринятый термин.
Ну так и какая разница клиенту, хранит библиотека только токены или заказы целиком
Да, всё так. Именно этому вопросу и посвящена вторая половина статьи — как жить с ненадёжными клиентами и какие риски возникают
Эм, как обеспечить цифровой подписью, что клиент передал правильные данные, если сервер сам данных не знает?
Это не так. Обеспечить консистентную репликацию БД очень сложно. Вот, например, вводная статья от разрабочтиков InnoDB: https://dev.mysql.com/doc/refman/8.0/en/replication-sbr-rbr.html
Во-первых, это достаточно сложный паттерн чтобы предлагать его имплементировать клиентам публичного API. Предоставить компонент для записи в локальные БД для каждой платформы не выглядит простой задачей, ну и вообще на разработчика API налагает много дополнительной ответственности.
Во-вторых, запись в локальную БД может быть неудачной или локальная БД может быть повреждена/стёрта.
Во-третьих, паттерн «клиент передаёт на сервер известный ему заказ» вообще чрезвычайно опасен. Сервер обязан дополнительно валидировать, что клиент не врёт и заказ действительно вот такой. Зачем тогда передавать сам заказ, достаточно его идентификатора.
Самое главное, я не вижу, каким образом это проще. Подмена синхронизации через API [у которого есть формальные интерфейсы и спецификация] синхронизацией через БД [у которой в лучшем случае есть документированная схема] почти всегда плохая идея даже если речь идёт о внутренних системах.
Если пользователи и так имеют доступ к системе под своим логином — то, грубо говоря, да. Разрешить пользователю на спец. странице получить токен для API [не обязательно хранить его в базе, можно и stateless], и с этим токеном они смогут делать автоматические запросы.
По ссылке написано прямо обратное