Hacker News Reader

Comment by jewbacca | Hacker News Reader

> 404 should be reserved for URL/route errors.

What dichotomy are you working off of here? It is absolutely a 404. How is this any less applicable to a DELETE request than it would be to a GET request for the same resource? What extra information would this new status status code carry?

----

> 10.4.5 404 Not Found

> The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10...

View on HN

Ok, so client requests "DELETE www.company.com/api/thing/1234" and gets a 404. Or even "GET www.company.com/api/thing/1234". Delete vs get doesn't matter.

Did 1234 not exist, or is "/api/thing" the wrong path?

404 is overloaded. It can mean two very different things.

> Did 1234 not exist, or is "/api/thing" the wrong path?

This doesn't matter. You shouldn't be trying to pull "1234" out of the URI. The identifier for the resource as far as the client is concerned is the URI, not some numeric component buried within it. Just treat the URI as an opaque piece of information – if you get a 404, it's the wrong URI. If you're trying to divine meaning from the constituent parts of the URI, then you're almost certainly making a mistake.

Yes, but is it the wrong URI because the path is wrong (and then I'll double check the docs and my code), or was the 404 because the code is correct but the specific item could not be found? All you are saying is "it doesn't matter", which is unhelpful and ignores the fact that these are completely different error conditions.

All server code for REST will be written in terms of /path/to/{ID}. We have a path, we have a instance ID, which each may be incorrect.

> is it the wrong URI because the path is wrong (and then I'll double check the docs and my code)

This is the source of the problem. REST APIs are hypertext-driven. They use links, like the web. You access resources by following links, not by constructing URIs. If you are reading the specification to find out which paths to use, then hard-coding them in your client software, then you don't have a REST architecture, you have something very different (which, unfortunately, some people insist on calling "REST" anyway).

REST revolves around hypertext. You don't hard-code paths, the server provides resources that link to one another. The client accesses the resources by following the links, not by constructing URIs itself.

If you have a REST architecture, then you can't get the path wrong in your client code because the path isn't in your client code. It's in a resource the server gives you.

> All server code for REST will be written in terms of /path/to/{ID}.

Perhaps, but the client should not be aware of this. The ID that a REST client uses is the URI.

> We have a path, we have a instance ID, which each may be incorrect.

The only ID that the client has is a URI, and if you get a 404, it means that there's no resource available for you to access with that ID. The client does not have a path, and the client does not have an instance ID. It only has a URI.

Ah, I think I understand what you're getting at now, that's a really interesting question.

I can't entirely back this up without probably days of reading RFCs, but my initial gut feeling is that making this distinction, which is not really possible in a truly general way (provided the URI is a syntactically correct HTTP URI), would be exposing internal implementation details in a way that would be conceptually inconsistent with other HTTP response statuses.

eg, how to usefully and consistently make the distinction:

    GET /asfd
    200 OK

    GET /qwer
    4XX We don't have that right now

    GET /zxcv
    4XX That is not even a thing

Keep in mind that the RESTful URI style is not part of the HTTP standard in any way. In HTTP, URIs can be random gibberish, even if they refer to "sibling" resources semantically. "You're on the right path" vs "What are you even talking about" is not an inherent concept in HTTP.

It might make sense in certain circumstances of RESTfully-modelled resource URIs layered on top of HTTP:

    GET /users/asfd
    200 OK

    GET /users/qwer
    4XX We don't have that right now

    GET /blarghs/asdf
    4XX That is not even a thing

But to describe this situation in an HTTP response status would be "mixing layers" and making assumptions in a way that opens a conceptually messy can of worms.

----

Disclaimer: I have no idea what I'm talking about and am not entirely convinced by my own argument. I'm always skeptical of "that's just not how it's done right now"-flavoured arguments, which this doesn't stop smelling like as I attempt to reason about it.

----

As practical matter, the body of the 404 response can describe the situation within the context of the application. And if your application is smart enough (though to do this in the general case is impossible or would require something like strong AI), you can use any of several more specific responses (Gone, Found, etc; depending on the context) if you're willing and capable of inferring a specific intent from the otherwise bad request.

"is /api/thing the wrong path" - is fixed by hypermedia, so 404 generally means that resource cannot be found.

Reply on news.ycombinator.com