Я создаю коллекцию ресурсов RESTful, которые работают следующим образом: (Я буду использовать "людей" в качестве примера):
GET /people/{key}
- returns a person object (JSON)
GET /people?first_name=Bob
- returns a list of person objects who "first_name" is "Bob" (JSON)
PUT /people/{key}
- expects a person object in the payload (JSON), updates the person in the
datastore with the {key} found in the URL parameter to match the payload.
If it is a new object, the client specifies the key of the new object.
Я чувствую себя довольно комфортно с дизайном до сих пор (хотя любой вход/критика приветствуется).
Я также хочу, чтобы иметь возможность перечислить список людей, однако я не уверен в RESTfulness моего дизайна. Вот что я имею в виду:
PUT /people
- expects a list of objects in JSON form with keys included in the object
("key":"32948"). Updates all of the corresponding objects in the datastore.
Эта операция будет идемпотентной, поэтому я бы хотел использовать "PUT". Однако его нарушение правила, потому что запрос GET на этот же ресурс не будет возвращать эквивалент того, что клиент просто PUT, но скорее вернет все объекты "люди" (поскольку в запросе не будет фильтров). Я подозреваю, что есть и другие правила, которые могут быть нарушены здесь.
Кто-то упомянул об использовании запроса "PATCH" в более раннем вопросе, который у меня был: ресурс REST со свойством List
"PATCH" звучит фантастически, но я не хочу использовать его, потому что он еще не широко используется и не совместим с множеством программ и API.
Я бы предпочел не использовать POST, потому что POST подразумевает, что запрос не является идемпотентным.
Есть ли у кого-нибудь комментарии/предложения?
Последующий:
Пока я не решался использовать POST, потому что он, по-видимому, является наименее общим знаменателем, можно сказать, что все операции RESTful и многое другое можно сказать об этой операции (в частности, это идемпотент), PUT не может использоваться, потому что его требования слишком узкие. В частности: ресурс не полностью переписан и эквивалентный ресурс не отправляется обратно из запроса GET на тот же ресурс. Использование PUT со свойствами вне его спецификации могут вызвать проблемы, когда приложения, api и/или программисты пытаются работать с ресурсом и встречаются с неожиданным поведением с ресурсом.
В дополнение к принятому ответу, Даррел Миллер имел отличное предложение, если операция абсолютно должна была быть PUT, и это должно было добавить UUID в конец пути ресурса, так что эквивалентный запрос GET вернет эквивалентный ресурс.