mdn в качестве спеки по http сойдет? w3 все же читается сложнее

ммм я бы w3 все ж рекомендовал... можешь сначала mdn что бы было проще

https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

да, это тоже открыто

ну, идемпотентность мне как-то на подкорке отпечаталась уже, да и в принципе она в большинстве случаев замечательно подкрепляется логикой (если логика присутствует, конечно)

ну просто есть любители кинуть ошибку что ресурса нет на DELETE запрос. Типа "да мне это и нужно!" а оно кидает.

или на PUT

я аж не знаю, какой извращенный ум до такого догадается

много таких. очень

ну либо сервер сначала сделал, а потом посмотрел

в случае с delete

или есть еще апи платежек всяких которые... ну типа ты платежку послал и если что-то в пути не так случилось - то прости прощай, если все было ок а ты просто ответ не получил - просто деньги второй раз спишем)

типа "чувак, удали мне номер..." —- "аааа, уже удалил, че ты там говорил? нет такого номера"

я аж не знаю, какой извращенный ум до такого догадается

я бы сказал что подобное по умолчанию у людей в головах. А уже потом они начинают думать

или есть еще апи платежек всяких которые... ну типа ты платежку послал и если что-то в пути не так случилось - то прости прощай, если все было ок а ты просто ответ не получил - просто деньги второй раз спишем)

та не)

у меня триггер на платёжки...) таких нету)

та не)

ты смеешься а я как-то систему завязал на метод апи такой (в блокчейнах) и потом страдал потому что сеть периодически падала)

потом просто разделил на отдельно создать транзакцию и послать транзакцию - идемпотентно, надежно, можно повторять хоть до посинения

ну за ваши эти модные блокчейны не скажу) в классических платёжках всё чуток иначе) там всё зависит от того, в какой момент времени ты отвалился)

надо бота завести который мониторит чат, слушает слова и кидает картинку triggered и упоминание человека

"DDD говно" -> Антон :) "я ваш SOLID на трубе шатал" -> Сергей...)

"DDD говно" -> Антон :) "я ваш SOLID на трубе шатал" -> Сергей...)

не меня тоже в ddd говно лучше запиши. Или "разделить на слои".

ну можно нескольких звать)

сервисбасы еще можно

саги те же

тоже Антон)

саги это да, болше к антону - я не шарю

ага, не шарит он) прикидывайся дальше)

окей, про идемпотентность put - да, post - нет в таком случае выходит так, что уникальные сущности должны быть созданы только через post?

на саги еще я могу затриггериться, для послушать

окей, про идемпотентность put - да, post - нет в таком случае выходит так, что уникальные сущности должны быть созданы только через post?

если айдишку клиент создает - то можно и через put

Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 *identical requests* is the same as for a single request.

ну то есть если операция идемпотентная - ты можешь через put/get/delete все делать. А если нет - добро пожаловать в мир post-ов

идентичные запросы

скорее получается наоборот

если айдишку создает сервер и нет уникальных полей - тогда можно юзать put

опять фп

а если клиент - тогда сугубо пост, ведь айдишка должна быть уникальной

если айдишку создает сервер и нет уникальных полей - тогда можно юзать put

ммм... нет, операция ж не идемпотентная. сервер на два одинаковых запроса тебе 2 разные айдишки сгенерит

не путай уникальность с идемпотентностью

PUT /users/id {} PUT /users/id {} одинаковый результат

POST /users {} POST /users {} разный

все сводится к сайд эффектам

все сводится к сайд эффектам

А Delete разве не должен удалять?

Ну то бишь в первый раз он удалит и скажит "я удалил это", а второй раз скажет "сорри, такого нет"

А Delete разве не должен удалять?

DELETE /users/{id} DELETE /users/{id} одинаковый результат - 204, все ок, ресурса больше нет

И такое получается через post фигачить надо типа сайд-эффект?

Ну то бишь в первый раз он удалит и скажит "я удалил это", а второй раз скажет "сорри, такого нет"

вот о чем я и говорю

DELETE /users/{id} DELETE /users/{id} одинаковый результат - 204, все ок, ресурса больше нет

NoContent

А ресурса нет - NotFound поидее

мысли вслух

А ресурса нет - NotFound поидее

это 404 и ошибка клиента что не является "ок"

это 404 и ошибка клиента что не является "ок"

ну так он удаляет удалённое

сам пидор

раз делает такое

ну так он удаляет удалённое

он мог повторить запрос если сеть лагнула

клиенту класть

он мог повторить запрос если сеть лагнула

а меня как сервера это должно волновать?)

Я запрос получил, действие выполнил

а меня как сервера это должно волновать?)

тебя это тоже не должно волновать - если кто-то хочет удалить удаленный ресурс - ну он уже удален так что мне работы меньше

верну ему 204 что ресурса больше нет)

тебя это тоже не должно волновать - если кто-то хочет удалить удаленный ресурс - ну он уже удален так что мне работы меньше

Ну по мне так логичнее таки ошибку вернуть...

если удаляют удалённое

Ну по мне так логичнее таки ошибку вернуть...

но в этом нет смысла ни для сервера ни для клиента

ресурса то не существует больше

это только добавляет лишней логики

ресурса то не существует больше

если тебе во все это сложно - для тебя есть json rpc

POST /deleteUser(id)

и все счастливы

ERROR: S client not available

а потом можно и graphql-ем обмазаться

и будет

mutation deleteUser(id: Number) { }

вооо

ресурса то не существует больше

ресурсы не важны - важно сделать удобно

вот это норм вещь

наконецта

ну то есть ни клиенту ни серверу никакого профита от того что бы кинуть ошибку на удаление ресурса которого не существует нет.

только усложнения

а потом можно и graphql-ем обмазаться

по мне так это недо-protobuf на жсоне

по мне так это недо-protobuf на жсоне

там вся соль в композиции данных

только усложнения

почему?

почему?

потому что тебе не хочется на клиенте обрабатывать эту ошибку и глушить ее.

Ты говоришь: "Эй мужик, ты делаешь хуитуууу!!!" и клиент такой "Ок, понял" и рисует юзеру "Сорри, вы сделали хуиту"

по мне так логично такое

Ты говоришь: "Эй мужик, ты делаешь хуитуууу!!!" и клиент такой "Ок, понял" и рисует юзеру "Сорри, вы сделали хуиту"

представь что ты открываешь апку и тыкаешь кнопку delete когда вьезжаешь в туннель. Связь резко рвется и запрос как бы на сервер ушел но ты получил таймаут. Твоя приложенька умная и просто повторит запрос. Но сервер уже возвращает ошибку.

ну то есть ни клиенту ни серверу никакого профита от того что бы кинуть ошибку на удаление ресурса которого не существует нет.

многим помогает переосознание того, что DELETE это не запрос действия на удаление, а запрос факта удаления. задача проверить наличие записи, сделать так, чтобы её не было, вернуть "ок" и как раз формулировка "сделать так, чтобы её не было" кладёт на то, есть она или нет изначально.

многим помогает переосознание того, что DELETE это не запрос действия на удаление, а запрос факта удаления. задача проверить наличие записи, сделать так, чтобы её не было, вернуть "ок" и как раз формулировка "сделать так, чтобы её не было" кладёт на то, есть она или нет изначально.

именно так.

есть - удалить - окей нет - уже хорошо - окей

это не процедура - это описание

представь что ты открываешь апку и тыкаешь кнопку delete когда вьезжаешь в туннель. Связь резко рвется и запрос как бы на сервер ушел но ты получил таймаут. Твоя приложенька умная и просто повторит запрос. Но сервер уже возвращает ошибку.

клиент перезагружает данные и видит то, что ты удалял уже удалено

все счастливы

это надо написать

ты я так понимаю клиенты вообще не пишешь?)

многим помогает переосознание того, что DELETE это не запрос действия на удаление, а запрос факта удаления. задача проверить наличие записи, сделать так, чтобы её не было, вернуть "ок" и как раз формулировка "сделать так, чтобы её не было" кладёт на то, есть она или нет изначально.

О

А вот это уже охуенная мысль

Спасибо

А подробнее есть где глянуть?

Ну там в rfc каком-нить

А подробнее есть где глянуть?

я это из головы взял, не думаю что там можно что-то глянуть

но можешь попробовать

А подробнее есть где глянуть?

https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html