Блог

Как новичок в spring, я хотел бы знать реальную разницу между:-

 @PostMapping
@PutMapping
@PatchMapping
 

Насколько я понимаю, это для обновления, но затем мы должны получить элемент по его идентификатору, а затем сохранить () его. Аналогично метод save() снова используется Post, который автоматически заменяет его идентификатором (PRIMARY). В моем приложении я могу использовать три из этих методов взаимозаменяемо.

Какой смысл иметь типы PATCH, POST, PUT, когда мы используем методы сохранения репозитория для всех?

Токены метода HTTP используются для определения семантики запроса таким образом, Чтобы компоненты общего назначения (браузеры, обратные прокси и т. Д.) Могли использовать информацию для интеллектуальных действий.

Самый простой из них заключается в том, что PUT имеет идемпотентную семантику; если http-ответ потерян, компонент общего назначения знает, что он может автономно повторить попытку отправки запроса. Это, в свою очередь, дает вам немного дополнительной надежности в ненадежной сети «бесплатно».

Тот факт, что ваш исходный сервер использует один и тот же механизм сохранения для каждого, является деталью реализации, что-то намеренно скрытое за «единообразным интерфейсом».

Разница между PATCH и POST неуловима; PATCH дает вам однозначный способ указать, что вложенный объект является документом исправления, и предлагает механизм для определения, какие форматы документов исправления понятны исходному серверу, ни один из которых вы не получаете только из POST.

Что менее ясно, по крайней мере для меня, так это то, позволяет ли семантика PATCH промежуточному компоненту делать что-то разумное с запросом — другими словами, позволяют ли дополнительные ограничения (относительно POST) посредникам делать что-то интересное?

Насколько я могу судить, семантика запроса на ИСПРАВЛЕНИЕ более конкретна, но не более конкретна — конечно, не так очевидно, как в случае безопасной или идемпотентной семантики запроса.

POST предназначен для создания совершенно нового объекта.

PUT заменит все свойства объектов за один раз.
Если оставить свойство пустым, значение в хранилище данных будет пустым.

PATCH выполняет частичное обновление объекта. Вы можете отправить ему только те свойства, которые должны быть обновлены. Запрос на ИСПРАВЛЕНИЕ со всеми включенными свойствами объекта будет иметь тот же эффект, что и запрос POST. Но это не одно и то же.

Метод HTTP — это соглашение, не специфичное для Spring, но являющееся основным элементом спецификации REST API.

Они гарантируют, что цель запроса ясна, и как поставщик, так и потребитель согласны с конечным результатом.
Вроде как педали или переключение передач в наших автомобилях. Это намного проще, когда все они работают одинаково.
Их переключение может привести к множеству несчастных случаев.

Для нас, разработчиков, это означает, что мы можем ожидать, что большинство REST API будут вести себя аналогичным образом, предполагая, что API реализован в соответствии со спецификацией или достаточно близко к ней.

POST / PUT / PATCH могут выглядеть одинаково, но есть небольшие различия. Как вы упомянули, методы PUT и PATCH требуют некоторого идентификатора объекта, который необходимо обновить.

В примере комбинированной конечной точки POST / PUT / PATCH отправка запроса с объектом, опуская некоторые его свойства. Как реагирует API?

1. Обновляйте только полученные свойства.
2. Обновите весь объект, очистив пропущенные свойства.
3. Попытка создать новый объект.

Как потребитель конечной точки узнает, какое из трех действий предпринял сервер?

Именно здесь метод HTTP и спецификация / соглашение помогают определить подходящий курс действий.

Spring может упростить метод сохранения, который может обрабатывать как создание, обновления, так и частичные обновления. Но это не обязательно относится к другим фреймворкам на Java или других языках.

Кроме того, ваше приложение может быть достаточно простым, чтобы обрабатывать POST / PUT / PATCH одним и тем же методом контроллера прямо сейчас. Но со временем, по мере усложнения вашего приложения, разделение проблем делает ваш код намного чище, более читаемым и доступным для обслуживания.