Вопрос по web-services, web, rest, http – Создайте один и несколько ресурсов, используя спокойный HTTP

16

На моем сервере API я определил этот маршрут:

POST /categories

Чтобы создать одну категорию, вы делаете:

POST /categories {"name": "Books"}

Я думал, что если вы хотите создать несколько категорий, то вы можете сделать:

POST /categories [{"name": "Books"}, {"name": "Games"}]

Я просто хочу подтвердить, что это хорошая практика для Restful HTTP API.

Или нужно иметь

POST /bulk

для того, чтобы позволить им делать какие-либо операции одновременно (создание, чтение, обновление и удаление)?

Error: User Rate Limit Exceeded wingy
Error: User Rate Limit Exceeded Neikos

Ваш Ответ

4   ответа
19

POST -> New Resource Location
POST -> New Resource Location
...

+1 за «прагматизм выполняет свою работу». Я также создаю API, и, имея тысячи ресурсов, я думаю, что массовое создание превосходит один POST на ресурс.
4

Error: User Rate Limit Exceeded

POST /categories/uploads/
[{"name": "Books"}, {"name": "Games"}]

    303 See Other
    Location: /categories/uploads/321/

(actually, now that I think about it, 201 might be better than 303)

GET /categories/uploads/321/

    200 OK
    Content-Type: application/json

    [{"name": "Books", "link": "/categories/Books/"},
     {"name": "Games", "error": "The 'Games' category already exists."}]
Почему я не могу вернуть созданные ресурсы в ответе POST напрямую? wingy
Похоже, Джулиан смотрит через мое плечо;)trac.tools.ietf.org/wg/httpbis/trac/ticket/347
@fumanchu: я полностью не согласен. Прочитай это:stackoverflow.com/a/1829913, Кроме того, Restful Web Services говорит: «Entity-body: должен описывать и ссылаться на вновь созданный ресурс. Представление этого ресурса приемлемо, если вы используете заголовок Location, чтобы сообщить клиенту, где этот ресурс действительно существует. & Quot;
Потому что это RPC, а не REST. Возвращенные представления, вероятно, не будут кэшированы; даже если вам удастся найти кеш, который кеширует ответы POST, он не будет кэшироваться по URI, который идентифицирует ресурс (очевидно, он идентифицирует создание ресурса).
11

Error: User Rate Limit Exceeded

  • You're making multiple resources, so you need to respond with multiple URLs. This means you can't use the redirect pattern: you'll have to send a list of URLs back in some form.

  • You have a problem in that bulk operations are often not very discoverable. Discoverability is one of the most important things about RESTfulness, as it means that someone can come along and figure out how to write a client without lots of help from the server author.

  • Dealing with partial failures when you've got bulk operations remains problematic. It's a problem with any other paradigm too (I've watched people tie themselves in knots over this when working with extensions to SOAP) so it isn't a surprise, but unless you can guarantee that all the creations will work, you're going to have to work out what happens when you make one resource and fail to make the second. (Also, if the bulk request wanted a third one done, would you go on and try that?)

Error: User Rate Limit Exceeded

2

Error: User Rate Limit Exceeded

Error: User Rate Limit Exceeded

Error: User Rate Limit Exceeded

POST /bulk [{"name": "Books"}, {"name": "Games"}]
202 Accepted | Location: /bulk/processing/status/resourceId

GET /bulk/processing/status/resourceId
entry = "REST in peace" | completed | 0 errors | /categories/category/resourceId
entry = "Walking dead" | processing | 0 errors ->

Error: User Rate Limit Exceeded

Error: User Rate Limit Exceeded

Похожие вопросы