11

I've the following endpoint:

a/{id}/b

and want to create a b with sending POST request to it. If a with given {id} is not found should I response with 404 NOT_FOUND or maybe with 409 CONFLICT?

It is to handle plain a/{id}, the trick is that here a subresource is used.

Opal
  • 275
  • 1
  • 2
  • 9
  • Possible duplicate of [How to handle business rules with a REST API?](https://softwareengineering.stackexchange.com/questions/250692/how-to-handle-business-rules-with-a-rest-api) – gnat Jan 24 '18 at 10:55

2 Answers2

16

404 NOT FOUND seems to be an appropriate response, because the resource with this ID does not exist. It's very clear to understand and you are expecting the same response if a/{id} is called.

409 CONFLICT does not seem to be the better choice, because in your example you will return a 409 when the parent resource was not found :).

But remember that the most important thing is be consistent in your API.

joshp
  • 3,451
  • 1
  • 21
  • 27
Dherik
  • 2,406
  • 20
  • 33
  • I agree. If you were to try to write to a folder that didn't exist, is it a conflict or a missing folder error? It seems more intuitive this way to me. – Neil Jan 24 '18 at 12:31
  • A "folder" you mean a path that does not exists? – Dherik Jan 24 '18 at 13:05
  • I mean a folder, like on the file system. – Neil Jan 24 '18 at 14:16
  • Can you detail the scenario? Because it depends. If the folder was expected for the server and (for whatever reason) are not there I think this is a _server_ error (5xx) not a client error (4xx). If this folder value was passed by the client to the resource (as the `id`), is 404. But if the folder was passed in the body this could be anything else (412, 422... something to represent "validation failed: folder does not exists"). It's a good question to ask and discuss. – Dherik Jan 24 '18 at 14:27
  • If you ask the server for file with path /nonexistent/help.html, and the folder /nonexistent doesn't exist, there is only one clear response to this. 404 file not found! There could even exist a /home/help.html, and the response would not differ. This is a REST application clearly, but I see no reason why the logic would change. The parent must exist first. – Neil Jan 24 '18 at 14:42
  • @Neil I agree with you. – Dherik Jan 24 '18 at 14:44
  • `This is a REST application clearly, but I see no reason why the logic would change. The parent must exist first.`Everything in the WWW is REST :-) that's the point. What's behind certain URI (static document or a web service) doesn't matter. – Laiv Jan 25 '18 at 15:38
7

In addition to @Dherik's answer.

URIs are identifiers, so we have to keep in mind that (/a/{id}/b is an identifier). The URI is meaningless for the WWW, and so is for the HTTP client.

404 is the right answer. In essence, the server is answering

I didn't find any resource with such id. Resource not found 1

Whether the missing resource is parent or child doesn't matter.

We, developers, see hierarchies and paths but HTTP clients don't. In other words, we read and see infirmation in these identifiers but HTTP clients don't. These treat URIs as meaningless strings.

In case of doubts, don't ask what code makes sense for you (human). Do ask, what code makes sense for the HTTP client. How do I want the HTTP client to behave?

Why? Because status codes make the client to behave in different ways. For example, 302. This code usually makes web browsers to redirect to a specific location (URI) informed in the response headers.

This might not be your case, but it's important to know about this. Ultimately, HTTP status codes are addressed to HTTP clients. Not to our applications. Not to persons.

1: 409 is rarely implemented as navigation error. It usually involves the execution of remote operations (delete, update, new, etc). But the URI should exist. Otherwise, 404 will prevail

Laiv
  • 14,283
  • 1
  • 31
  • 69