The proplem from my job.I'm Android Developer,My co-work is RESTFul API developer(Call him ResA）.

My App is Map App,user click map,app search nearly device ids from map.then search device information from server database by id.

SomeDay,user tell me can both search 2+ devices.After my debug I found a device return json is:

{code:200,msg:"success",data:null}

normal return is:

{code:200,msg:"success",data:{userId:1,userName:"AA"}}

I think this is a error,Request ResA Edit API return code can't be 200 ,because null is not normal data.

But He send me picture.content is sql query(not found any data),ask me why the query not found and not have error(mean null is normal)?

I answered him: search list return empty list is fight,because emtpy list is list.the api seach single data return null is wrong,because null not data(not normal data).

Is my understanding right or wrong? thank your answer.

---

I found two similar ones：
Use 404 or 200 when null result (REST) [duplicate]
Status code for middleware? 200 or 4XX , 5XX?
but this is return list ,not is single data.

The proplem from my job.I'm Android Developer,My co-work is RESTFul API developer(Call him ResA）.

My App is Map App,user click map,app search nearly device ids from map.then search device information from server database by id.

SomeDay,user tell me can both search 2+ devices.After my debug I found a device return json is:

{code:200,msg:"success",data:null}

normal return is:

{code:200,msg:"success",data:{userId:1,userName:"AA"}}

I think this is a error,Request ResA Edit API return code can't be 200 ,because null is not normal data.

But He send me picture.content is sql query(not found any data),ask me why the query not found and not have error(mean null is normal)?

I answered him: search list return empty list is fight,because emtpy list is list.the api seach single data return null is wrong,because null not data(not normal data).

Is my understanding right or wrong? thank your answer.

---

I found two similar ones：
Use 404 or 200 when null result (REST) [duplicate]
Status code for middleware? 200 or 4XX , 5XX?
but this is return list ,not is single data.

• java
• android
• rest
• server
• api-design

Share Improve this question Follow edited Mar 12 at 3:09 卡尔斯路西法 asked Mar 12 at 2:31 卡尔斯路西法卡尔斯路西法 14299 bronze badges 3

• yes, an empty list and null are different things. when no data is found you should get either http status 404 or data={} – mr mcwolf Commented Mar 12 at 4:39
• @mrmcwolf not http state ,this is body content. – 卡尔斯路西法 Commented Mar 12 at 5:55
• yes, but you are using restful (rest over http) so you can take advantage of the http status. in that case 404 is a "Not Found" tag. – mr mcwolf Commented Mar 12 at 6:49

Add a comment  | 

2 Answers 2

Sorted by: Reset to default 1

Is my understanding right or wrong? thank your answer.

It's a little bit off.

An important idea in REST is the "uniform interface constraint", which means (among other things) that everyone understands all of the messages the same way (common semantics); in other words, the implementation details don't matter

So GET /something always means give me the current representation of the resource something, and 200 OK (within the context of a GET request) always means that the response body is a representation of the request resource, and 404 Not Found always means that the server did not find a current representation of the target resource.

But there's nothing in REST that requires you to support a specific resource model, or to use a particular rule for determining which resources in your model currently have representations.

For example, consider this JSON document:

null

If we were to ask a web server for the current representation of that document, using the correct URL in the request, the response we would expect back would look something like

200 OK
Content-Type: application/json

null

If that's a surprise, then think about it more.

---

That said, this isn't really a "REST" issue; it's an "understanding our resource model / designing our representations" question, and REST deliberately doesn't have an opinion on those.

In this case, you've really got two things to consider - first, whether "there is no data in the database" necessarily means that the resource has no current representation, and second, if the resource does have a representation when there is no information in the database, what should that representation look like.

For example, you might be better off with a representation that looks like this when there is one row in the database

data: [{userId:1,userName:"AA"}]

and a representation that looks like this when there are no rows in the database

[]

Representations are, in some sense, messages, and the same kinds of trade-offs arise when we need to design the schema.

Both you and your colleague have taken perfectly reasonable positions that are correct under some circumstances, and you are probably going to need to sit down (possibly with an arbiter) to identify which circumstances you are currently in, and which design decisions have the best short and long term impacts given those circumstances.

---

For instance,i ask bank clerk:'this is my bank card, can you tell me remaining manoy?",bank clerk May tell me :"I can;t find the card information” or "sir,remaining $0",not tell me : "I find some thing ,no something."

Yes - you are confusing domain semantics with resource semantics. When I ask a web server for /accounts/1234567890, I'm asking for a document about account 1234567890 not the account itself, and the document may exist even in cases where the account doesn't.

REST doesn't say that your documents need to be like everybody else's documents; it only says that the messages about your documents mean the same thing as the the messages about everybody else's documents (we can use general purpose tools to understand messages about documents without being concerned with anybody's documents being special).

There are domains where it makes sense to say "document not found" when the document identifier isn't one that we know about. And there are other domains where that does not make sense, where instead you should send a "document about nothing" back to the user.

And that's the part that I'm certain you are wrong about: your assumption that, because "document not found" is the correct design choice in some cases, that it must therefore be true that it is the correct design choice in all cases.

(Good news: lots of people are wrong about this; it's not an easy thing.)

In our case, the API is not designed correctly (incorrect multiplicity of user-device relationship).

Also, this API is not REST API (the REST API is built around resources, HTTP response codes are used, etc.).

---

Here's what a correct REST API might look like in our case:

Request:

GET /users/{user_id}/devices

Responce (HTTP status code 200):

{
   “devices”: []
}