В чем отличие метода PUT и PATCH?

Что-то вроде:
- PATCH: 404 (Not found) при отсутствии, 200 (OK) при существовании.
- PUT: 201 (Created) при отсутствии, 200 (OK) при существовании.

Ну и не стоит забывать, что PUT передаёт полное состояние ресурса, а PATCH - только частичное, как правило.

Забей. Есть GET и POST, остальное — от лукавого.

(ну да, ну да, есть ещё OPTIONS — но это в большинстве случаев для прикладух должно быть прозрачно)

Есть GET и POST, остальное — от лукавого.

что б с тебя штрафы POST’ом списывались, умник

По задумке есть отличия, а по факту синоним. Не заморачивайся. Имей в виду, что от реализации к реализации разница может быть, но зачастую будет полностью отсутствовать, а сам используй PATCH, если у тебя нет прямой необходимости сделать с помощью PUT что-то сродни upsert.

PUT - это замена. PATCH - это обновление. PUT’ом ты отправляешь объект полностью и заменяешь им существующий/создаёшь новый. PATCH’ем ты можешь обновлять какие-то части уже существующего объекта.

+1. Если мы, к примеру, тупо транслируем REST-запрос в SQL UPDATE, то в PUT надо передавать полный список полей, в отсутствующие поля будет записан null; а PATCH не будет обновлять отсутствующие поля. (Как передавать в PATCH null, не помню.)

И да, как написал WitcherGeralt, PUT это SQL UPSERT, а PATCH – SQL UPDATE.

что б с тебя штрафы POST’ом списывались, умник

Два чая этому анониму, он определённо секёт фишку. =)

А можете разжевать фишку для несекущих? Я бы согласился с Miguel, честно говоря.

Попытка провести параллели запросов HTTP с запросами к БД - это какая-то выдуманное, искусственное упрощение. Мне кажется.

Попался тут вопрос на hh.ru что-то вроде «расскажите путь прохождения запроса в LAMP». По-моему максимально идиотский вопрос. Но подозреваю, что правильным ответом они имели ввиду что-то из этой же серии, где запрос HTTP смешан в одну кучу с запросами к БД.

что б с тебя штрафы POST’ом списывались, умник

объясните, плиз, интересно, но не врубаюсь

А можете разжевать фишку для несекущих?

PUT идемпотентен, POST нет.

PUT идемпотентен, POST нет

А что именно может помешать реализовать обработку POST с проверкой повтора?

PUT обязан быть идемпотентным, а POST - нет.

Ничто не мешает. Каждый волен изголяться как ему заблагорассудится. В т.ч. даже нарушая стандарты (например, делая PUT неидемпотентным, потому что идемпотентность – отнюдь не очевидная задача). Однако паттерны (а REST – это паттерн) существуют в т.ч. для того чтобы облегчать понимание твоего кода другими. И чтобы не было кто в лес кто по дрова.

REST – это паттерн

т.е. ==

выдуманное, искусственное упрощение

У ТС нигде не упоминается, что он говорит про REST.
Тогда понятно, спасибо.

REST – это не более чем способ использования философии и фич HTTP с максимальной эффективностью. Так что «мы говорим Ленин HTTP – подразумеваем партия REST». А кому пофиг, тем достаточно GET и POST.

Занятно как REST стало означать «20 минут выбираем нужный http-метод, и ещё час спорим какие http-статусы возвращать», хотя в оригинальном white paper про rest емнип вообще http не упоминался.

Впрочем, про максимальную эффективность можно и поспорить. Например, GraphQL упаковывает в один HTTP-запрос несколько REST-запросов. Но исторически это уже развитие исходной идеи, по сути ей не противоречащее.

Хз что там было в white paper. Вся идея – это минимум глаголов и идемпотентность. Методы выбираются тривиально из описанных выше соображений (20 минут – ну, новичку и подольше может потребоваться к этой извращенской идее привыкнуть), а статусы (как и конкретный формат сообщений) – это уже детали реализации (один хрен в статус много информации не засунешь, поэтому реальная ошибка как правило отдаётся в теле ответа).

Никто не знает что такое REST потому что это очень плохо определённая расплывчатая хрень, которую каждый понимает так как ему хочется.

Книжки читать не пробовали?

Ок, ладно. :) Тот твой камент выше, который я плюсанул, вполне конкретен и не расплывчат. Просто как и всякий паттерн, REST не является догмой и оставляет массу свободы и для реализации, и для люфтов/нарушений. Тем более, что паттерн не самый тривиальный. Например, уж на что простая вещь – синглтон, но и копий вокруг него сломано немеряно, и извращения встречаются типа getInstance() с параметрами.

Ну попробуй хотя бы вот это объяснить:

https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

5.1.3 Stateless

request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server.

Т.е. у меня получается не может быть базы данных, верно? Иначе же это не REST.

Ой, всё! Утомилася я.

Если я хочу отправить запрос на добавление книги и внутри есть поле «автор», то оно может в момент времени t1 вернуть ошибку, в момент времени t2 вернуть 201 и успешно добавить книгу. Потому что в момент времени t1 такой автор ещё не существовал в базе, а в момент t2 он уже есть. Т.е. получается запрос на добавление книги нельзя никак назвать stateless. REST это полнейший бред сивой кобылы. Есть некоторые разумные идеи в этой диссертации, но в целом это выглядит как толстый троллинг.

Да и пох.

Т.е. получается запрос на добавление книги нельзя никак назвать stateless.

Stateless означает, что перед отправкой запроса ты не должен устанавливать какой-то контекст, держать соединение и т. п. Вот есть stateful ftp, там надо отдельными командами устанавливать режим, менять каталог, логинится, и т.д. Получение токена доступа для rest «это другое», ты получаешь токен, который дальше нужно передавать, а в ftp ты ничего не получаешь, а факт логина записывается в этот самый state.

Ух, как грубо. Сразу переход на личности, класс.

Я признаю конкретные вещи, например, jsonapi - там всё понятно. А с рестом вашим идите на фиг, вы уже всех задолбали своим REST, чёртовы сектанты и фанатики. Идите в гуманитарщину и там бесконечно переливайте из путого в порожнее, не надо в айтишку с этим дерьмом лезть.

Сразу переход на личности, класс.

А то. :) «Переубедить мне вас всё равно не удастся, поэтому сразу перейду к оскорблениям.» (c)

Stateless означает, что перед отправкой запроса ты не должен устанавливать какой-то контекст, держать соединение и т. п.

Что такое «какой-то контекст»? Если у меня есть сессия у каждого юзера на стороне сервера, и я там храню какие-то данные (возможно от предыдущих запросов), то фанатки REST говорят, что это уже не рест. Почему? А если я в базе логирую активность юзера и в зависимости от его предыдущих запросов определяю какое будет поведение у его будущих запросов?

Получение токена доступа для rest «это другое», ты получаешь токен, который дальше нужно передавать, а в ftp ты ничего не получаешь, а факт логина записывается в этот самый state.

Почему такая же логика не применятся для остальных запросов, выходящих за пределы логики логина и аутентификации? Если юзер создал сущность X, то это сохраняется на сервере и никакой токен ты не получаешь, ты просто делаешь запрос и сервер помнит, что X уже существует. Иначе ты с каждым запросом должен просто отправлять всю базу данных получается (ну или то её подмножество, которое касается твоего запроса).

stateless относится к протоколу. Не к сущностям, которыми манипулируют с помощью апи.

А если я в базе логирую активность юзера и в зависимости от его предыдущих запросов определяю какое будет поведение у его будущих запросов?

Ну смотри, допустим в апи есть функция вставки значения в БД, и два режима, просто вставляем, или вставляем и пишем в лог файл. stateful будет, если мы сначала вызываем «включить логирование», которое включает его допустим на это подключение, но не на параллельные запросы, а потом вызываем вставку. Stateless же будет вызываем вставку, передавая параметр «включить логирование». То, что запрос завершится по разному в зависимости от того, что уже есть в БД на state(full|less) не влияет, так как не относится к протоколу.

Если не знаком с ftp, еще SQL stateful протокол. Если у тебя оборвалось соединение с БД, то ты должен опять, допустим, выставить кодировку, уровень изоляции, и т.д. Начать заново транзакцию. В HTTP оборвалось соединение - просто отправляй новый запрос в новом.

ебанашка, тебя REST заставляет constraint на поле author добавлять?

stateless относится к протоколу.

Мы говорим про REST. REST это не протокол, поэтому к нему понятие stateless относиться не может (с чем я согласен), но тут почему-то https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm говорится, что REST должен быть stateless.

Не к сущностям, которыми манипулируют с помощью апи.

Где грань между сущностями апи и не сущностями апи? У меня есть сущность «настройки юзера», например. Если юзер меняет запросом на изменение настроек отображаемый язык в последующих запросах, то это REST или нет потому что не stateless? Настройки юзера это такая же сущность апи как и остальные. Почему нет?

Stateless же будет вызываем вставку, передавая параметр «включить логирование».

Почему настройки логирования не могут быть сущность апи?

так как не относится к протоколу.

Так в том-то и дело, что REST это не протокол и не говорит что относится к протоколу и что не относится. Это просто вообще ни о чём, получается.

При чём тут констрейнт? Ты какой-то совсем глупенький, лучше сдрисни из треда, не мешай дядям разговаривать.

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

С точки зрения протокола POST, PUT, PATCH не отличаются ничем. Всё остальное это только дополнительная семантика, которую, в принципе, можно и не соблюдать, всё на уровне договорённостей.

С точки зрения протокола POST, PUT, PATCH не отличаются ничем

какого протокола, болезный?

Если юзер меняет запросом на изменение настроек отображаемый язык в последующих запросах, то это REST или нет потому что не stateless?

Это может быть stateless если мы не считаем передачу session ID состоянием, но это однозначно не REST. В HTTP и соответственно в REST язык задаётся заголовком запроса, а не меняется отдельным запросом. И это 100% stateless т.к. этот заголовок передаётся с каждым запросом.

какого протокола, болезный?

HTTP. Вообще-то тут он прав. Семантические различия POST/PUT/PATCH обеспечиваются прикладным слоем, а не собственно HTTP-сервером.

HTTP

а RFC2608/2616 говорит, что есть разница.

Я в курсе. Тут уместно про «the difference between theory and practice». In practice, как можно заметить по обсуждению выше, все х@й клали. =)

ичо, есть какой-то другой, practice HTTP, не описанный в RFC? в котором нет строк про fundamental difference between the POST and PUT requests?

Конечно. Я ж написал про обсуждение выше.

In practice, как можно заметить по обсуждению выше, все х@й клали.

как можно заметить по многим обсуждениям тут, мир полон дегенератов, но это никак не влияет на протокол, которым Legioner пытается прикрыться

Да жизнь вообще боль.

Протокол это соглашения, по которым передаются байты.

и про какое из соглашений ты тут спизднул, мудило?

REST это не протокол, поэтому к нему понятие stateless относиться не может (с чем я согласен), но тут почему-то https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm говорится, что REST должен быть stateless.

Это шаблон, а шаблон может диктовать, что протокол stateless. Раз у апи lastfm написано, что оно рест, я уже знаю, что если соединение отвалилось, мне надо просто повторить запрос в новом, не выставляя заново какие-то настройки.

Где грань между сущностями апи и не сущностями апи?

Абстрагирование. Следи внимательно за этим маятником, мы концентрируемся на протоколе, в мире нет ничего, кроме протокола, ни тупых юзеров, ни языков, ничего. Есть HTTP, есть SQL. Первый stateless, второй stateful. Подумай в чем между ними разница.

Почему настройки логирования не могут быть сущность апи?

Они и есть. Stateful и stateless протокол делает это по разному, я приводил пример.

У меня есть сущность «настройки юзера», например. Если юзер меняет запросом на изменение настроек отображаемый язык в последующих запросах, то это REST или нет потому что не stateless?

Дьявол, как говорится, в деталях. Этот язык применится на вообще все запросы апи, на запросы токена, который выполнил запрос, или же на запросы получения инфы из профиля этого юзера?

Язык это просто пример. Я знаю, что он через хедер обычно передаётся. Другой аналогичный пример: глобальные настройки фильтрации по департаментам, например, сущности принадлежат различным департаментам и юзер может в своих настройках задать чтобы ему при любом запросе отдавало сущности только из его департамента или из указанного списка департаментов.

Можно сделать stateful – хранить настройки в сессии, можно stateless – передавать частью запроса (кастомным заголовком или в теле – не принципиально).

Причём передавать с запросом можно как настройки целиком, если они компактные, так и сохранённый где-то на сервере код настроек.

Кстати, выбор между сессией и запросом может быть форсирован этим соображением goingUp:

Дьявол, как говорится, в деталях. Этот язык применится на вообще все запросы апи, на запросы токена, который выполнил запрос, или же на запросы получения инфы из профиля этого юзера?