6

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?

Lulzim
  • 547
  • 4
  • 9
  • 22

2 Answers2

1

"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" }
Tim
  • 8,036
  • 2
  • 36
  • 52
  • 2
    if we return 404 for "No data found", what would we return for "Request not found, or bad url", how do we distinguish cases like this – Lulzim Mar 28 '15 at 13:06
  • To be RESTful a URL represents a resource. If the resource is not found, it's a 404. Just because you have code on your back end that understands the URL doesn't make it found. If you really need clients to distinguish then return JSON or XML with further information about the error. Just because its a 404 doesn't mean it can't convey data. – Tim Mar 28 '15 at 13:08
  • The thing is I dont want to handle specific messages like "album not found" from the back-end, isn't it front-end job to write msg depending on the status from back-end? that's why i am looking smth that can distinguish msg like "No entitiy found" vs "bad url, or no url found" – Lulzim Mar 28 '15 at 13:15
  • 1
    Firstly, HTTP status codes don't distinguish between **entity** not found and **url** not found. As far as HTTP is concerned the entity and the URL are the same thing. – Tim Mar 28 '15 at 13:26
  • 1
    Secondly, the front end's job is to interpret the response and display a message, sure. But as the back end has the knowledge of what does and doesn't exist, it is best placed to add further context. – Tim Mar 28 '15 at 13:30
0

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

nomadus
  • 859
  • 1
  • 12
  • 28