Там, где речь идёт о деньгах, обычно лучше передать с клиента ту цифру, которую клиент видел глазами (напрямую в виде значения, или закодированную в offer_id) и валидировать её на сервере. Потому что между этими двумя моментами (клиент видел цифру стоимости доставки — клиент подтвердил заказ) что-то могло измениться (закончилась скидка, увеличился сурж), и клиент будет неприятно удивлён.
Два пользователя изменили в оффлайне одно и то же поле одного и того же объекта (поправили описание товара, например). Как такой формат патчей поможет "перебазировать" изменения не потеряв изменения?
Никак. Чудес не присходит. Вопрос в том, как применить изменения, если пользователи патчили разные поля.
А если стоимость заказа меньше 9000, то в качестве delivery_fee и total клиент сможет указывать любое положительное число? Скажите же скорее адрес этого магазина - скуплю его за бесценок.
Так этот "конец транзакции" применяет её или отменяет?
В тексте не transaction, а transition. Если существует двусмысленность (любого из терминов), следует выбрать не-двусмысленный вариант (для обоих терминов).
Во-вторых, независимо от отсутствия / наличия единого стандарта, даты в интернете вы можете получить в каком угодно виде. См. вторую часть фразы — «Исключения возможны только там, где вы на 100% уверены, что в мире существует только один стандарт для этой сущности, и всё население земного шара о нём в курсе.»
И что хорошего в запросе данных некешируемым методом создания ресурса?
POST не является методом создания ресурса. «The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics» — https://www.rfc-editor.org/rfc/rfc7231#page-25
В вопросе кэширования результатов «тяжёлых» вычислений нас интересует прежде всего серверный кэш, а не клиентский, правда же? Доступ к нему вполне можно и через POST организовать — вновь вопрос того, что мы считаем важным: индицировать семантику операции (вы запускаете сложный алгоритм) или сэкономить какие-то байты на клиентском кэшировании.
Наконец, результаты POST могут кэшироваться (хотя я лично не рекомендую это делать), см. тот же RFC.
Почему хорошо удалять заказ неидемпотентным методом создания ресурса?
POST не является методом создания ресурса. «The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics» — https://www.rfc-editor.org/rfc/rfc7231#page-25
То, что метод может быть неидемпотентным не означает, что он обязан быть идемпотентным (как раз наоборот, далее в тексте предлагается все методы обязательно делать идемпотентными). POST здесь используется именно для того, чтобы соответствовать процитированной семантике HTTP-методов согласно RFC. `PUT /orders/{id}/cancellation` тоже допустим.
Не разумно. Кто не хочет читать доку не будет её читать, а для того, кто с ней знаком, это будет постоянным раздражителем.
Очевидно, процент тех, кто всё-таки прочитает доку будет выше по сравнению с ситуацией без раздражителя. Ну а стоит ли раздражение многих этой дополнительно подушки безопасности — зависит от цены ошибки.
Деньги за превышения лимитов платить партнёрам, так что ответственность в любом случае их. Но, очевидно, они будут их платить с несколько большей охотой, если производитель API будет помогать им бороться с фродом.
Гм. И как же вы оценили качество, поделитесь методологией?
Я, скажу честно, под .NET не программировал с 2007 года. Но вот первый взгляд на статистику меня настораживает. Топ пакетов NuGet по их же официальной статистике:
Newtonsoft.Json — фреймворк для работы с JSON (что само по себе выглядит странно, что за платформа такая, что в 2022 году не поддерживает JSON нативно)
serilog — библиотека логирования
Castle.Core — набор из четырёх никак не связанных между собой пакетов [вот с таким вебсайтом](http://www.castleproject.org/) и документацией в виде .md-шек в репе
Swashbuckle.AspNetCore.Swagger — обёртка над сваггером
AWSSDK.Core — обёртка над AWS API
Итого, один пакет решает проблемы недоработанной платформы, одна либа логирования и две с половиной обёртки над чужими API. Что здесь примечательно? В топе нет ни одного пакета, который привносил бы в платформу какие-то новые возможности, которые выделили бы её среди других платформ.
Если честно, затрудняюсь понять, как оценить качество этого добра, и уж решительно не понимаю, бейзлайном чего это можно считать.
CRDT и представляют формат описания атомарных изменений, в точности как в тексте описано.
Может фиксируется, а может и нет. Оффер может содержать все параметры заказа, а может просто валидировать, что клиент их не поменял.
Нет.
Нет.
С трудом себе это представляю. Если я анимировал положение элемента, то отменить это действие как если б его не было уже не получится.
Там, где речь идёт о деньгах, обычно лучше передать с клиента ту цифру, которую клиент видел глазами (напрямую в виде значения, или закодированную в offer_id) и валидировать её на сервере. Потому что между этими двумя моментами (клиент видел цифру стоимости доставки — клиент подтвердил заказ) что-то могло измениться (закончилась скидка, увеличился сурж), и клиент будет неприятно удивлён.
Никак. Чудес не присходит. Вопрос в том, как применить изменения, если пользователи патчили разные поля.
Действительно, URL должен быть `PUT /v1/orders/drafts/{draft_id}/confirm`. Поправлю, спасибо.
Я не обсуждаю здесь детали технической имплементации.
Я не понял этого комментария.
В тексте не transaction, а transition. Если существует двусмысленность (любого из терминов), следует выбрать не-двусмысленный вариант (для обоих терминов).
Во-первых, это неправда. Есть ещё как минимум RFC 3339 https://www.rfc-editor.org/rfc/rfc3339 и RFC 7231 https://www.rfc-editor.org/rfc/rfc7231#section-7.1.1.1
Во-вторых, независимо от отсутствия / наличия единого стандарта, даты в интернете вы можете получить в каком угодно виде. См. вторую часть фразы — «Исключения возможны только там, где вы на 100% уверены, что в мире существует только один стандарт для этой сущности, и всё население земного шара о нём в курсе.»
POST не является методом создания ресурса. «The POST method requests
that the target resource process the representation enclosed in the
request according to the resource's own specific semantics» — https://www.rfc-editor.org/rfc/rfc7231#page-25
В вопросе кэширования результатов «тяжёлых» вычислений нас интересует прежде всего серверный кэш, а не клиентский, правда же? Доступ к нему вполне можно и через POST организовать — вновь вопрос того, что мы считаем важным: индицировать семантику операции (вы запускаете сложный алгоритм) или сэкономить какие-то байты на клиентском кэшировании.
Наконец, результаты POST могут кэшироваться (хотя я лично не рекомендую это делать), см. тот же RFC.
Тот, который указан в теле запроса
POST не является методом создания ресурса. «The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics» — https://www.rfc-editor.org/rfc/rfc7231#page-25
То, что метод может быть неидемпотентным не означает, что он обязан быть идемпотентным (как раз наоборот, далее в тексте предлагается все методы обязательно делать идемпотентными). POST здесь используется именно для того, чтобы соответствовать процитированной семантике HTTP-методов согласно RFC. `PUT /orders/{id}/cancellation` тоже допустим.
Очевидно, процент тех, кто всё-таки прочитает доку будет выше по сравнению с ситуацией без раздражителя. Ну а стоит ли раздражение многих этой дополнительно подушки безопасности — зависит от цены ошибки.
Это весьма дельная мысль, спасибо.
В черновиках (src/ru/drafts)
Деньги за превышения лимитов платить партнёрам, так что ответственность в любом случае их. Но, очевидно, они будут их платить с несколько большей охотой, если производитель API будет помогать им бороться с фродом.
Гм. И как же вы оценили качество, поделитесь методологией?
Я, скажу честно, под .NET не программировал с 2007 года. Но вот первый взгляд на статистику меня настораживает. Топ пакетов NuGet по их же официальной статистике:
Newtonsoft.Json — фреймворк для работы с JSON (что само по себе выглядит странно, что за платформа такая, что в 2022 году не поддерживает JSON нативно)
serilog — библиотека логирования
Castle.Core — набор из четырёх никак не связанных между собой пакетов [вот с таким вебсайтом](http://www.castleproject.org/) и документацией в виде .md-шек в репе
Swashbuckle.AspNetCore.Swagger — обёртка над сваггером
AWSSDK.Core — обёртка над AWS API
Итого, один пакет решает проблемы недоработанной платформы, одна либа логирования и две с половиной обёртки над чужими API. Что здесь примечательно? В топе нет ни одного пакета, который привносил бы в платформу какие-то новые возможности, которые выделили бы её среди других платформ.
Если честно, затрудняюсь понять, как оценить качество этого добра, и уж решительно не понимаю, бейзлайном чего это можно считать.
А, ясно. Пожалуй, на этом стоит закончить обсуждение.