What REST PUT/POST/DELETE calls should return by a convention?

1. According to the "REST ideology" what should be in the response body for a PUT/POST/DELETE requests?

2. What about return codes? Is HTTP_OK enough?

3. What is the reason for such conventions, if any?

I've found a good post describing POST/PUT differences: POST vs PUT But it still doesn't answer my question.

Forgive the flippancy, but if you are doing REST over HTTP then RFC7231 describes exactly what behaviour is expected from GET, PUT, POST and DELETE.

Update (Jul 3 '14):
The HTTP spec intentionally does not define what is returned from POST or DELETE. The spec only defines what needs to be defined. The rest is left up to the implementer to choose.

Overall, the conventions are “think like you're just delivering web pages”.

For a PUT, I'd return the same view that you'd get if you did a GET immediately after; that would result in a 200 (well, assuming the rendering succeeds of course). For a POST, I'd do a redirect to the resource created (assuming you're doing a creation operation; if not, just return the results); the code for a successful create is a 201, which is really the only HTTP code for a redirect that isn't in the 300 range.

I've never been happy about what a DELETE should return (my code currently produces an HTTP 204 and an empty body in this case).

Creating a resource is generally mapped to POST, and that should return the location of the new resource; for example, in a Rails scaffold a CREATE will redirect to the SHOW for the newly created resource. The same approach might make sense for updating (PUT), but that's less of a convention; an update need only indicate success. A delete probably only needs to indicate success as well; if you wanted to redirect, returning the LIST of resources probably makes the most sense.

Success can be indicated by HTTP_OK, yes.

The only hard-and-fast rule in what I've said above is that a CREATE should return the location of the new resource. That seems like a no-brainer to me; it makes perfect sense that the client will need to be able to access the new item.

By the RFC7231 it does not matter and may be empty

How we implement json api standard based solution in the project:

post/put: outputs object attributes as in get (field filter/relations applies the same)

delete: data only contains null (for its a representation of missing object)

status for standard delete: 200

I like Alfonso Tienda responce from https://stackoverflow.com/questions/2342579/http-status-code-for-update-and-delete

Here are some Tips:

DELETE

> - 200 (if you want send some additional data in the Response) or 204 (recommended). > > - 202 Operation deleted has not been committed yet. > > - If there's nothing to delete, use 204 or 404 (DELETE operation is idempotent, delete an already deleted item is operation successful, so you can return 204, but it's true that idempotent doesn't necessarily imply the same response) > > Other errors: > > - 400 Bad Request (Malformed syntax or a bad query is strange but possible). > - 401 Unauthorized Authentication failure > - 403 Forbidden: Authorization failure or invalid Application ID. > - 405 Not Allowed. Sure. > - 409 Resource Conflict can be possible in complex systems. > - And 501, 502 in case of errors.

PUT

> If you're updating an element of a collection > > - 200/204 with the same reasons as DELETE above. > - 202 if the operation has not been commited yet. > > The referenced element doesn't exists: > > - PUT can be 201 (if you created the element because that is your behaviour) > - 404 If you don't want to create elements via PUT. > > - 400 Bad Request (Malformed syntax or a bad query more common than in case of DELETE). > - 401 Unauthorized > - 403 Forbidden: Authentication failure or invalid Application ID. > - 405 Not Allowed. Sure. > - 409 Resource Conflict can be possible in complex systems, as in DELETE. > - 422 Unprocessable entity It helps to distinguish between a "Bad request" (e.g. malformed XML/JSON) and invalid field values > - And 501, 502 in case of errors.