Pull to refresh
375
0

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

Send message

Это и есть чистый сокет.

Я думаю количество реальных систем, использующих JSON-RPC на чистых сокетах, вряд ли превышает количество пальцев на моей левой руке.

Возможно, переставлю абзац выше, спасибо.

но не указали, что там перед хостом может быть еще и userinfo

Указал: «помимо указанных компонентов в стандарте перечислены разнообразные
исторические наслоения (например, передача логинов и паролей в URL или
использование не-UTF кодировки), которые нам в рамках вопросов
дизайна API неинтересны.»

Ну и ссылка на RFC 3986, имхо, так же могла бы быть уместной.

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*.

В стандарте написано ровно то же, что и я написал ;)

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). Будет разобрано в следующей главе.

Но, наверное, best practice из gRPC (и тогда уж GraphQL) стоит добавить, согласен

Это фактически один из кастомных форматов для описания списков изменений. В целом можно и так, хотя это плохо расширяется если нужно, например, удалять элементы массивов.

выталкивать данные или затягивать (опрашивать)

poll — опрашивать ;)

Можно и pull, но polling кмк более общепринятый термин.

  1. Ну так и какая разница клиенту, хранит библиотека только токены или заказы целиком

  2. Да, всё так. Именно этому вопросу и посвящена вторая половина статьи — как жить с ненадёжными клиентами и какие риски возникают

  3. Эм, как обеспечить цифровой подписью, что клиент передал правильные данные, если сервер сам данных не знает?

  4. Это не так. Обеспечить консистентную репликацию БД очень сложно. Вот, например, вводная статья от разрабочтиков InnoDB: https://dev.mysql.com/doc/refman/8.0/en/replication-sbr-rbr.html

Во-первых, это достаточно сложный паттерн чтобы предлагать его имплементировать клиентам публичного API. Предоставить компонент для записи в локальные БД для каждой платформы не выглядит простой задачей, ну и вообще на разработчика API налагает много дополнительной ответственности.

Во-вторых, запись в локальную БД может быть неудачной или локальная БД может быть повреждена/стёрта.

Во-третьих, паттерн «клиент передаёт на сервер известный ему заказ» вообще чрезвычайно опасен. Сервер обязан дополнительно валидировать, что клиент не врёт и заказ действительно вот такой. Зачем тогда передавать сам заказ, достаточно его идентификатора.

Самое главное, я не вижу, каким образом это проще. Подмена синхронизации через API [у которого есть формальные интерфейсы и спецификация] синхронизацией через БД [у которой в лучшем случае есть документированная схема] почти всегда плохая идея даже если речь идёт о внутренних системах.

Если пользователи и так имеют доступ к системе под своим логином — то, грубо говоря, да. Разрешить пользователю на спец. странице получить токен для API [не обязательно хранить его в базе, можно и stateless], и с этим токеном они смогут делать автоматические запросы.

Статистически, для гарантированного развития алкогольной болезни печени
мужчинам надо употреблять около 70 г чистого этанола в день в течение 8
лет, в то время как женщинам — всего 20 г. Это примерно 150 мл водки, либо 500 мл сухого вина или 1000 мл пива.

По ссылке написано прямо обратное

При злоупотреблении спиртными напитками в гепатотоксичных дозах
далеко зашедшие стадии АБП (выраженный фиброз и цирроз печени)
формируются лишь у 10 - 20% пациентов [2,3], что отражает влияние ряда
других факторов (генетических, стиля приема алкоголя и т.д.) на
прогрессирование поражения печени

Всё как с кожаными водителями, ага. Те, говорят, вообще права покупают.

Не собираясь ввязываться в дискуссию, не могу тем не менее не заметить, что вот это

По пунктам - на сегодняшний день я не видел в общем доступе ни одной современной адекватной литературы, популярного выступления, признания проблемы или просто полноценной и качественной лекции по следующим вопросам:

…Какая минимальная частота для сенсоров необходима?
…Какие могут быть допуски погрешности определения дистанции?

и т.д. — аргумент примерно уровня «ваши ГМО-овощи недостаточно исследованы». А что, кто-то замерил, какая погрешность определения дистанции у кожаных мешков? Или кто-то посчитал, сколько ложно-позитивных препятствий видят человеки?

Беспилотный автомобиль не должен демонстрировать каких-то частот и допусков — беспилотный автомобиль должен водить лучше живого человека, причём в очень конкретных цифрах — количество аварий на километр пробега.

Чем это отличается от обычного PATCH тогда, хочется поинтересоваться, и к чему весь этот разговор.

CRBT — несомненно, очень красивая концепция. У неё есть одна проблема — она к реальному миру лишь частично. В реальном мире нетранзитивные изменения всегда есть, в какую обёртку их ни заворачивай.

Приведу пример, опираясь на всю тот же кейс заказа кофе. Допустим, пользователь создал заказ на 200 мл капучино, а потом с двух разных устройств отредактировал его — на одном выставил 400 мл, на другом 500 мл.

Логика CRBT диктует нам, что для транзитивности этих изменений нужно представить их не как абсолюты, а как транзитивные изменения — +200 и +300 мл соответственно. И результат мержа двух операций тогда — 700 мл капучино. Но как бы здравый смысл подсказывает нам, что вот чего пользователь не хотел абсолютно точно, так это 700 мл капучино.

Мы даже можем дать ему интерфейс, в котором он не может выбрать цифру, а только жать кнопки +100 / -100, и формально мы тогда сможем применить CRBT-формат. Но в реальном мире ситуация не изменилась: пользователь абсолютно точно не хотел сделать «+100» — он хотел выставить объём, а наши транзитивные операции генерировал просто потому, что другой возможности ему не предоставили.

В частности, 2022-09-19 16:46:00 — валидная дата с т.з. RFC 3339, но невалидная с т.з. ISO8601. Запись 2022-09-19T16:46:00-00:00 валидна с т.з RFC, но невалидна с т.з. ISO

Information

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