Software Engineering
rest http layers http-response
Updated Tue, 26 Jul 2022 23:03:27 GMT

Do web applications use HTTP as a transport layer, or do they count as an integral part of the HTTP server?

Given an HTTP server (e.g. Apache, IIS) and a web application (user code running in the server using PHP, ASP.NET and the likes), which of those can decide which HTTP status code to return for any request?

Or rather, is a "web application" to be interpreted as an integral part of "server" as used in the HTTP RFCs? The latter (RFC 7230) is pretty short on that:

An HTTP "server" is a program that accepts connections in order to service HTTP requests by sending HTTP responses.

Since the actual response is generated by a web application (excluding static resources), I'd say the web application is actual part of the server.

However, apart from the eternal "which HTTP status code to use in [arbitrary situation]?" discussions, there also is the discussion "Should web applications even use HTTP status codes?", which I'd like a normative answer to.

See for example the Google Maps REST API. They return 200 for every repsonse, which can be interpreted as "The request ended up at the HTTP server, so that part went OK (200)". Any application error that happens that is returned in the message body as a JSON status, up till the point of NOT_FOUND.

Is this correct? Shouldn't a request for GET /Clients/123 return a 404 when that client doesn't exist? Then what about GET /clients.php?id=123, assuming clients.php exists?

Or does 404 really and only mean "I don't know what you're trying to do, but I'm not going to serve you a resource as there is no resource at (a part of) that URI", "resource" meaning "a (routed) file or directory", which should only be returned by the server when someone forgot to deploy the ClientService application?

Do status code only work for the HTTP part of things, or is a web application part of the server, allowing it to utilize the appropriate status codes where they fit, using HTTP status codes as API response codes?


404 means "the resource you asked for doesn't exist." It's up to the server to decide when that response is appropriate. Google has apparently interpreted it to mean "your API request was malformed." Other REST APIs might also interpret it to mean "your request was well-formed, but you are asking for something which does not exist." This is why you need to read the API docs.

The "server," in turn, is (as your RFC quote indicates) anything that responds to HTTP requests appropriately. If you build a server out of a gigantic web application framework, that's your business. The only requirement is that the client gets the semantically-correct response in any given situation. It will often be the case that the web application is better suited to make that decision than (say) Apache's out-of-the-box behavior, but you can and should set this up in whatever way makes the most sense for your situation.

Comments (3)

  • +1 – To the RFCs, you have a server and a client and that's the whole model. They do not care that, on your box, Apache is calling into some external code. They only describe the required behavior of the system as a whole. In practice, the web application has enough control over the server's behavior that it makes the most sense to make decisions there. But again, this is just sensible design. RFCs don't enter into it. — Jan 22, 2015 at 14:56  
  • +0 – My answer is that anything which you choose to make part of the server is part of the server. The only requirement is that, at the end of the day, the client gets the correct status codes and response bodies. — Jan 22, 2015 at 15:00  
  • +3 – Look at the quote you pulled from RFC 7230. A server is anything that responds to client requests with appropriate HTTP responses. It doesn't matter if it's just a flat file server or if you're using mod_whatever with Apache to call into a web application. If it responds to client requests, it's a server. The RFC does not describe how the server is supposed to locate the requested resources; calling into external code is a perfectly valid strategy. — Jan 22, 2015 at 15:13