LINUX.ORG.RU

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

 ,


0

2

Я так понимаю, что в PUT, при отсутствии записи создается новая, при ее наличии изменяются данные записи, а PATCH новую запись не создает и только изменяет ее. Верно? Тогда какие ответы и коды должны быть в PATCH, если записи нет? и в PUT какие ответы должны быть при наличии записи и при ее отсутствии?

★★

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

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

sanwashere ★★ ()
Последнее исправление: sanwashere (всего исправлений: 1)

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

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

Miguel ★★★★★ ()

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

WitcherGeralt ★★ ()
Последнее исправление: WitcherGeralt (всего исправлений: 2)

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

fulmar_lor ()
Последнее исправление: fulmar_lor (всего исправлений: 1)
Ответ на: комментарий от fulmar_lor

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

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

dimgel ★★★★ ()
Последнее исправление: dimgel (всего исправлений: 2)
Ответ на: комментарий от anonymous

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

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

dimgel ★★★★ ()
Ответ на: комментарий от dimgel

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

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

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

Toxo2 ★★☆ ()
Ответ на: комментарий от anonymous

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

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

Qwentor ★★★★★ ()
Ответ на: комментарий от Toxo2

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

maxcom ★★★★★ ()
Ответ на: комментарий от Toxo2

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

dimgel ★★★★ ()
Последнее исправление: dimgel (всего исправлений: 3)
Ответ на: комментарий от dimgel

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

т.е. ==

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

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

Toxo2 ★★☆ ()
Ответ на: комментарий от Toxo2

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

dimgel ★★★★ ()
Последнее исправление: dimgel (всего исправлений: 1)
Ответ на: комментарий от dimgel

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

PolarFox ★★★★★ ()
Ответ на: комментарий от dimgel

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

dimgel ★★★★ ()
Последнее исправление: dimgel (всего исправлений: 1)
Ответ на: комментарий от PolarFox

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

dimgel ★★★★ ()
Последнее исправление: dimgel (всего исправлений: 1)
Ответ на: комментарий от dimgel

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

fulmar_lor ()
Ответ на: комментарий от fulmar_lor

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

dimgel ★★★★ ()
Ответ на: комментарий от dimgel

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

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.

fulmar_lor ()
Ответ на: комментарий от dimgel

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

fulmar_lor ()
Ответ на: комментарий от fulmar_lor

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

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

goingUp ★★★★★ ()
Ответ на: комментарий от dimgel

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

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

fulmar_lor ()
Ответ на: комментарий от fulmar_lor

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

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

dimgel ★★★★ ()
Ответ на: комментарий от goingUp

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

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

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

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

fulmar_lor ()
Ответ на: комментарий от fulmar_lor

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

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

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

goingUp ★★★★★ ()
Ответ на: комментарий от fulmar_lor

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

goingUp ★★★★★ ()
Ответ на: комментарий от goingUp

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

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

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

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

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

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

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

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

fulmar_lor ()
Ответ на: комментарий от fulmar_lor

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

anonymous ()
Ответ на: комментарий от Toxo2

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

Legioner ★★★★★ ()
Ответ на: комментарий от fulmar_lor

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

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

dimgel ★★★★ ()
Последнее исправление: dimgel (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

dimgel ★★★★ ()
Ответ на: комментарий от anonymous

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

dimgel ★★★★ ()
Последнее исправление: dimgel (всего исправлений: 1)
Ответ на: комментарий от dimgel

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

anonymous ()
Ответ на: комментарий от dimgel

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

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

anonymous ()
Ответ на: комментарий от Legioner

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

anonymous ()
Ответ на: комментарий от fulmar_lor

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?

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

goingUp ★★★★★ ()
Ответ на: комментарий от dimgel

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

fulmar_lor ()
Ответ на: комментарий от fulmar_lor

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

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

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

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

dimgel ★★★★ ()
Последнее исправление: dimgel (всего исправлений: 2)
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.