4 ms·
Can't bulk delete though. Should a super-user be able to bulk delete? The status codes are: /api/users: GET 200 OK POST 201 Created (or 205 thanks lgierth)
by elchief 13y ago
Can't bulk delete though. Should a super-user be able to bulk delete?
The status codes are:
/api/users:
GET 200 OK
POST 201 Created (or 205 thanks lgierth)
PUT 204 No Content
DELETE 405 Method Not Allowed
PATCH 204 No Content
/api/users/123:
GET 200 OK
POST 405 Method Not Allowed
PUT 200 OK
DELETE 204 No Content
PATCH 200 OK
return 404 if resource not found, or 410 Gone if you know it once existed
return 400 (or 422) and list of errors on invalid input.
return 401 if need to login.
return 403 if logged in but not allowed to do something.
return 409 Conflict on currency control issue.
- batbomb 13y agoYou can't bulk GET either. I wish there was a BATCH keyword with some 10x/20x codes to enable pipelined HTTP methods. SPDY/HTTP2 should help with some of that.
- lgierth 13y agoI'd rather go with 205 in cases where a resource is created/changed/deleted, it instructs the agent to reset its view of the resource which the request originated from. http://httpstatus.es/205 http://httpstatus.es/205
- lgierth 13y agoAnd also I'd avoid 400 for invalid input in general, since it's meant to reject request entities with bad syntax, or incoming data that simply isn't HTTP. IMO 422 is a better match, it indicates semantic errors. http://httpstatus.es/400 http://httpstatus.es/400 http://httpstatus.es/422 http://httpstatus.es/422
- aaronem 13y agoThe PATCH verb seems underspecified and warty to me. Why not instead accept, on a PUT request, a Range header [1] whose byte-range-spec defines the range to be replaced in the document? Along with an entity consisting of the partial content to use in the replacement, this seems to provide everything the PATCH verb does, plus a complete absence of the ambiguity involved in "[description of changes]". Say maybe thus: GET /users/123 HTTP/1.1 Host: www.example.com Connection: keep-alive HTTP/1.1 200 OK Content-Type: text/json Content-Length: 41 {"name":"Joe","email":"joe@example.com"} PUT /users/123 HTTP/1.1 Host: www.example.com Connection: keep-alive Range: 24-27 j.random.hacker HTTP/1.1 200 OK Content-Type: text/json; charset=ISO-8859-1 Content-Length: 53 {"name":"Joe","email":"j.random.hacker@example.com"} [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14...
- wereHamster 13y agoHow would you patch multiple fields? Using json to patch json is more reliable. Also, if somebody changes the email before your request, your request will modify the document into an invalid json.
- aaronem 13y agoYou could handle multiple fields with Content-Type: multipart/byteranges and multiple byte-range-specs in the Range: header. The versioning problem can be trivially handled by means of the entity tag mechanism [1]. Our notional RFC need only specify that servers supporting partial PUT requests must include an ETag header [2] in every GET response, and that a client issuing a partial PUT request on a given resource must include an If-Match header [3] with the entity tag it received in its most recent GET response. The server can then compare the request's If-Match value with the current entity tag for the resource. If they match, the server updates the entity and responds with 204 No Content; otherwise, the server responds with 409 Conflict, whose response body is the complete entity and whose headers include the matching ETag, so that the UA can identify the conflict and present it to the user for resolution in whatever fashion it sees fit. Your point regarding blind byte-range modification of structured data ("Using json to patch json is more reliable") is not without merit, but belongs at a higher level of abstraction than that at which HTTP operates. If you want to take the JSON document through a thaw-edit-freeze cycle, you can do it on the client and just PUT the result as a complete entity. [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.11 http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.1... [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.19 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14... [3] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14...
- myhf 13y agoByte-ranges aren't idempotent like complete documents and key/value pairs are. You would need a vector-clock reference as well as the byte-range to let the server resolve ambiguity in your byte-range.
- 13y ago
- weavie 13y agoThis is where REST just breaks down. In any app I've written it always gets to the stage where I'm left with the choice of breaking away from a truly restful api, or firing off multiple requests. Sometimes REST wins, sometimes efficiency wins, but they really shouldn't be mutually exclusive choices.
- zimbu668 13y agoYou can bulk delete ff you have a resource that represents multiple users: DELETE /client/acme_inc/users