В REST есть POST или PUT, наиболее подходящий для работы upsert?

Ответ 1

Если пользователь отправляет ключ "k1", я обновляю его в базе данных. Рассматривается ли это POST или PUT.

В соответствии с спецификацией HTTP:

Метод PUT запрашивает, чтобы закрытый объект хранился в запрошенном Request-URI. Если Request-URI ссылается на уже существующий ресурс, закрытый объект СЛЕДУЕТ считаться модифицированной версией той, которая находится на исходном сервере. Если Request-URI не указывает на существующий ресурс и что URI может быть определен как новый ресурс запрашивающим пользовательским агентом, исходный сервер может создать ресурс с этим URI.

Поэтому я считаю, что использование PUT для вставки или обновления совершенно законно, при условии, что в обоих случаях URI известен заранее. Если вы используете ключ как часть URI (как k1 в http://www.somewhere.com/resources/k1), это должно быть так. Однако, чтобы быть идеальным RESTful, GET на тот же URL-адрес также должен позволить вам загрузить ресурс.

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

Я не думаю, что эту операцию можно считать RESTful, потому что она делает две вещи. Кажется, он предоставляет макрос для удовлетворения потребностей конкретного клиента, а не простой доступ к данным. Стандартный дизайн RESTful будет

• Получение списка ключей путем отправки GET в родительский URL. В приведенном выше примере это будет http://www.somewhere.com/resources;
• Удаление каждого из этих ключей путем отправки DELETE на http://www.somewhere.com/resources/k1;
• Добавление замены, отправив PUT на http://www.somewhere.com/resources/k2.

Это менее четкое сокращение, но я думаю, что было бы законно удалять все ресурсы, отправив один запрос DELETE на http://www.somewhere.com/resources.

Ответ 2

Идея операции upsert заключается в том, что у клиентов есть информация о/определении структуры данных и отправка данных с ключевым значением. Таким образом, модель запроса для операции upsert очень похожа на операцию обновления с ключом, включенным в качестве примера ниже:

/customers/jimmy

Ожидаемый способ обновления существующей записи - PUT. Поэтому ваш выбор должен быть PUT.

POST обычно используется для вставки новой записи с совершенно новым контентом, как в приведенном ниже примере:

POST /customers HTTP/1.1
Content-Type: ...
Content-Length: ...
Host: server.yourdomain.com
Accept: ...
User-Agent: ...

id      jimmy
name    jimmy
Occupation   Stackoverflower

Таким образом, в вашем случае вам не нужна операция POST, потому что PUT для операции upsert также охватывает это.

Здесь критический вопрос об использовании upsert - насколько вероятен доверие к вашему клиенту в отношении операции upsert. Если клиент хочет вставить новую запись с существующим ключом, что произойдет? В вашем случае вы должны обрабатывать этот запрос как обновление, потому что запросы на вставку и обновление поступают в один и тот же api, и у вас есть существующая запись. Это вопрос, на который нужно ответить на вашей стороне о дизайне.

Ответ 3

Ответ Polly Shaw верен, но я хотел бы упомянуть, что если сообщение скорее всего будет неполным (отсутствует идентификатор, когда ресурс еще не создан), глагол PATCH будет немного правильнее.

https://tools.ietf.org/html/rfc5789

Это очень тонкая настройка.

Ответ 4

Если вы все смешиваете, вы, вероятно, не делаете REST. Из RESTful Web-сервисы: Основы POST и PUT имеют отличный сценарий использования:

To create a resource on the server, use POST.
To retrieve a resource, use GET.
To change the state of a resource or to update it, use PUT.
To remove or delete a resource, use DELETE.

Итак, рассмотрите POST как отправку нового билета в блог и PUT, чтобы изменить существующее значение.

Удаление должно выполняться как отличительная операция с глаголом DELETE. Поскольку "удалить все" до обновления не кажется хорошей идеей.