Как мне следует разработать REST API?

#spring #rest #http

#spring #rest #http

Вопрос:

Я создаю REST API с spring framework. Затем я забеспокоился, поэтому начал публиковать.

Когда есть данные, как показано ниже,

GET /users/1

 {
   "name": "mike",
   "age": 21
}
 

В настоящее время REST API разработан следующим образом.

PUT /users/1

 {
   "name": "mike"
}
 

При запросе с помощью PUT, как указано выше, имя изменяется, а отсутствующий атрибут age становится нулевым следующим образом.

GET /users/1

 {
   "name": "mike2",
   "age": null
}
 

PATCH /users/1

 {
   "name": "mike2"
}
 

При запросе ИСПРАВЛЕНИЯ, как указано выше, имя изменяется, а возраст отсутствующего атрибута не изменяется следующим образом.

GET /users/1

 {
   "name": "mike2",
   "age": 21
}
 

Я хочу знать, соответствует ли это правилам REST API.

Если это не подходит, как мне запросить, хочу ли я изменить имя и удалить возраст в одном запросе?

Мне нужна помощь.

Ответ №1:

Настоятельно рекомендуется ознакомиться с RFC

Протокол передачи гипертекста RFC 7231 (HTTP / 1.1): семантика и содержание https://www.rfc-editor.org/rfc/rfc7231

В частности, обратите пристальное внимание на раздел 4.3 Определения методов

https://www.rfc-editor.org/rfc/rfc7231#section-4.3

«Метод POST запрашивает, чтобы целевой ресурс обрабатывал представление, заключенное в запросе, в соответствии с собственной специфической семантикой ресурса».

«Метод PUT запрашивает, чтобы состояние целевого ресурса было создано или заменено состоянием, определенным представлением, заключенным в полезной нагрузке сообщения запроса».

То есть вы обнаружите различия в том, как обрабатывается действие обновления (некоторые люди используют POST, некоторые используют PATCH, многие используют PUT), в зависимости от семантики ресурсов, специфичных для их реализации.

В вашем примере кажется, что семантическая реализация PUT, зависящая от ресурса, обрабатывает отправленный элемент данных как полную замену — и поскольку вы не включили элемент age, он остается нулевым.

PATCH действительно предназначен как глагол для выполнения частичного обновления, см.:

Метод исправления RFC 5789 для HTTP

https://www.rfc-editor.org/rfc/rfc5789

«Метод PATCH запрашивает, чтобы набор изменений, описанных в объекте запроса, был применен к ресурсу, идентифицированному с помощью запроса-URI. Набор изменений представлен в формате, называемом «документом исправления», идентифицируемом типом носителя.»

«Разница между запросами PUT и PATCH отражается в том, как сервер обрабатывает вложенный объект для изменения ресурса, идентифицированного с помощью запроса-URI. В запросе PUT вложенный объект считается модифицированной версией ресурса, хранящегося на исходном сервере, и клиент запрашивает замену сохраненной версии. Однако с исправлением вложенный объект содержит набор инструкций, описывающих, как ресурс, находящийся в настоящее время на исходном сервере, должен быть изменен для создания новой версии. Метод ИСПРАВЛЕНИЯ влияет на ресурс, идентифицированный с помощью запроса-URI, а также может иметь побочные эффекты для других ресурсов; т. Е. Новые ресурсы могут быть созданы или изменены существующие путем применения ИСПРАВЛЕНИЯ. »

«ИСПРАВЛЕНИЕ не является ни безопасным, ни идемпотентным»

«Нет гарантии, что ресурс может быть изменен с помощью ИСПРАВЛЕНИЯ. Кроме того, ожидается, что разные форматы документов исправлений будут подходить для разных типов ресурсов и что ни один единый формат не будет подходящим для всех типов ресурсов. Следовательно, не существует единого формата документа исправления по умолчанию, который должны поддерживать реализации. »

«Клиенты должны выбирать, когда использовать PATCH, а не PUT. Например, если размер документа исправления больше, чем размер новых данных ресурса, которые будут использоваться в PUT, тогда может иметь смысл использовать PUT вместо PATCH . Сравнение с POST еще сложнее, потому что POST используется самыми разными способами и может включать операции, подобные PUT и PATCH, если сервер выберет. Если операция не изменяет ресурс, идентифицированный запросом-URI предсказуемым образом, POST следует рассматривать вместо PATCH или PUT «.

Документы в формате JSON см. в разделе

RFC 6909 — Исправление для обозначения объектов JavaScript (JSON)

https://www.rfc-editor.org/rfc/rfc6902

«Исправление JSON определяет структуру документа JSON для выражения последовательности операций для применения к документу JavaScript Object Notation (JSON); он подходит для использования с методом исправления HTTP. Тип носителя «application / json-patch json» используется для идентификации таких документов исправлений.»

Кроме того, вы можете найти эти ресурсы полезными

https://restfulapi.net/http-methods/

https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods

https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/PATCH

https://en.wikipedia.org/wiki/Patch_verb

http://jsonpatch.com/

https://microservices.io/book