What should be the response of GET and DELETE methods in REST?

Question

In REST, suppose the client invoked the findAll method (GET)- which would simply return the list of entities(DTOs) to the client with HTTP status code 200. Now, let's say client has invoked a DELETE method removeObject(Object object). The object in the parameter doesn't exist in the database, and typically it would return HTTP status code 400. I want the client to know this real reason of 400 in a more manageable way (less panic) . Now the need of a status code / description arises which wasn't necessary during the GET method.

I want the client to get a consistent RESPONSE for all the messages. Is there any guideline / best practices for what to return in REST based APIs?

iTollu · Answer 1 · 2017-03-17T20:25:42.890

What do you mean by REST? Let's suppose, we refer to Roy Fielding and Http 1.1 standard.

According to standard, DELETE is idempotent method. I.e. if you request DELETE more than once, side-effects would be the same. I.e. all the same record in DB would be marked as "deleted" or be absent.

First of all, to request DELETE, you request a resource. Say, http://some.url/to/resource. If it never was present - you should respond with 404.

Section "9.7 DELETE" of the standard says:

A successful response SHOULD be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted, or 204 (No Content) if the action has been enacted but the response does not include an entity.

If you don't remove a record completely from DB and want to communicate on subsequent requests that resource had been deleted and is no longer available, then the standard, section "10.4.11 410 Gone", says:

The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed.

But using this response code or providing it for some time period is not necessary, and response could be also 404. So use it, if you want to differentiate, whether a resource had been deleted or had never been present.

Forget findAll() :p Replace it with some method which returns a list of DTOs — Tahniat Ashraf, Mar 17 '17 at 20:06
@tahniat-ashraf I've edited my answer. It is now more correct, according to standard, and with additional link. — iTollu, Mar 17 '17 at 20:26

score 0 · Answer 2 · answered Mar 17 '17 at 19:54

0

Status code of 400 is fine but you then also return some object that the frontend can parse and comprehend (i.e. json). This way, your frontend gets more info about the error and optionally override it before presenting it to the user. Some pretty basic and barely functional pseudocode:

Backend:

return(status_code=400,
       body={message: {type: "error", description: "some text here"})

Frontend:

if (status_code >= 400):
    console.log(json.loads(response).message.description)

answered Mar 17 '17 at 19:54

Srdjan Grubor

2,366
13
15

A status code of 400 means that the request was malformed, I would try avoid this one as it may cause confusion – Dai Bok Mar 17 '17 at 20:04
@DaiBok https://stackoverflow.com/a/6123801/1121879 https://stackoverflow.com/questions/5604816/whats-the-most-appropriate-http-status-code-for-an-item-not-found-error-page 400, 412, or 404 is what should be used if he receives an object that is not in the database (which is what the OP was talking about). 200 is not acceptable if the object being deleted can't be found. – Srdjan Grubor Mar 17 '17 at 20:10
Please see section 9.7 https://tools.ietf.org/html/rfc2616#section-9.7 – Dai Bok Mar 17 '17 at 20:18
@DaiBok Hmm.. the wording is tricky there but it does not specify what should be done when the server does not "intend to delete the resource". There is a distinction between `intending` and `doing` the delete op so while the spec indicates that you _can_ return a 200, it doesn't mean you _have_ to if there's an error. – Srdjan Grubor Mar 17 '17 at 20:29

Dai Bok · Accepted Answer · 2017-03-17T20:18:12.790

-1

I would expect an Rest api to respond with a 200 when deleting an object. Anything else usually means something went wrong with my request.

If I requested an object after it had been deleted, I would then expect the API to return 404, or something of that nature.

Please refer to section 9.7 of RFC 2616

https://tools.ietf.org/html/rfc2616#section-9.7

edited Mar 17 '17 at 20:18

answered Mar 17 '17 at 19:55

Dai Bok

3,065
2
46
60

But a typical client would want to know what has happened in the server side. – Tahniat Ashraf Mar 17 '17 at 19:57
I'm not sure i understand. The client knows he wants to delete an object. So first he gets it. Then he asks to delete it. If he wants to check it was deleted, he can try get it again? – Dai Bok Mar 17 '17 at 20:01
If I understand correctly, what you are implying is,if the client here gets a 404 error in DELETE, it should indicate that the object requested is not in a state to be deleted and the client doesn't need to retry the request. So simply returning 404 is good enough? – Tahniat Ashraf Mar 17 '17 at 20:04
Yes. If i try deleting an object that is already deleted, I would expect an API to return a 404. Indicating that someone deleted it before me. – Dai Bok Mar 17 '17 at 20:07
1

thanks :) I think I got the idea. This [link](http://stackoverflow.com/questions/2342579/http-status-code-for-update-and-delete) helped too – Tahniat Ashraf Mar 17 '17 at 20:12
1

No problems, hope it helps you. I've added a link to the rfc. It's quite useful to read if you creating your first API. Good luck – Dai Bok Mar 17 '17 at 20:21
"or something of that nature"? sad panda. – cutmancometh May 22 '18 at 19:41

What should be the response of GET and DELETE methods in REST?

3 Answers3