CODEWITHSUNDEEP
restrestful-url
Lulzim
Lulzim

Reputation: 547

What status code should I response with when there is no data found in my database

I am wondering what status code would I response with in my else statement from the code below:

       if (album) {
            res.status(200).json({error: false, data: {channel_id: album.attributes.channel_id, id: album.id}});
        } else {
            res.status(200).json({error: false, data: {message: 'There is not album found with this name'}});
        }

I don't want to leave both of them 200 as I want from front end to manage messaged thru status code, for ex if it returns 200 I would say "Created Successfully" while in else case I would display "No data found".

What is your suggestion?

Upvotes: 6

Views: 12543

Answers (2)

nomadus
nomadus

Reputation: 909

Although, I agree with above post, I would also consider HTTP status 200 for some cases.

For example, you have Post and Post_Comments entities. When you request comments for give Post Id, you can have either have 404 (an error which you then need to handle on your REST API consumer side) or 200 which means that everything is OK and an empty array is returned. In the HTTP status 200 case, you do not need to handle an error. As an example, see how FB treats HTTP codes https://apigee.com/about/blog/technology/restful-api-design-what-about-errors

Upvotes: 0

Tim
Tim

Reputation: 8606

"No data found" should be 404.

"Created Successfully" should be 201.

For the 201 you should also specify a Location header for where another request can access the new resource.

Refs:
201 http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2
404 http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.5

UPDATE:

I thought I'd expand on this, because the comments below point to thought processes I've battled with myself.

GET /some/thing responding 404 Not Found may mean a database entity not found, but could also mean there is no such API end point. HTTP itself doesn't do much to help differentiate these cases. The URL represents a resource. It's not a thing in itself to be considered differently from the thing it represents.

Some APIs respond 400 when a request is made to a non-existant endpoint, but personally I don't like this as it seems to contradict the way web servers respond to normal resource requests. It could also confuse developers building client applications, as it suggests something is wrong in the HTTP transport rather than in their own code.

Suppose you decide to use 404 for missing database entities and 400 for what you consider bad requests. This may work for you, but as your application grows you'll uncover more and more scenarios that simple status codes just can't communicate on their own. And this is my point..

My suggestion is that all API responses carry meaningful data in the body. (JSON or XML, or whatever you're using). A request for an invalid url may look like:

HTTP/1.1 404 Not Found

{ "error": "no_endpoint", "errorText":"No such API end point" }

Upvotes: 1

Related Questions