4 ms·

Transport is TCP/UDP/etc. HTTP is part of the application layer, see https://en.wikipedia.org/wiki/OSI_model https://en.wikipedia.org/wiki/OSI_model and https:/

Transport is TCP/UDP/etc. HTTP is part of the application layer, see https://en.wikipedia.org/wiki/OSI_model https://en.wikipedia.org/wiki/OSI_model and https://en.wikipedia.org/wiki/Application_layer https://en.wikipedia.org/wiki/Application_layer. >If you sent a perfectly semantically valid HTTP request for a resource that doesn't exist on the remote Requesting a path (via the application layer) that doesn't exist is a client error, hence the 4XX. But, say, if your website has a search bar and a client searches for "blahblah-thisdoesntexist" and gets no results, the webpage should return a 200 (the request was valid: the client sent form data to an existing resource and it was processed successfully) with something like "no results found" in the body -- because the search function itself is above the application layer. This is what I mean about "is the CC is authorized or not" being above the application layer. >Its set of status codes clearly reflect details of the underlying application. This is where I think you're wrong: HTTP status codes reflect the result of the HTTP request itself, not the next application in the chain, if one exists. This can also be expressed if we look lower down the chain. If my HTTP request gave me a 404, should an error be shown in the TCP stack? Well no, because TCP doesn't know or care about HTTP, as far as it's concerned the TCP connection is established and happy. Likewise, in this example, the API HTTP stack doesn't care about whether the data was a CC or something else or what the result was: as far as the HTTP stack is concerned, some JSON got passed in and parsed properly, and some output got sent back, and everything went well so "200".

sagichmal 7y ago
> OSI I understand OSI, but it's not a useful model in this circumstance, because it draws no distinction between the HTTP layer and the business logic served over HTTP. The complexities of that interface is what we're talking about. > HTTP status codes reflect the result of the HTTP request itself, not the next application in the chain, if one exists. Let's say I request /robotz.txt and I get 404 Not Found. How do you maintain that 404 is a result of "the HTTP request itself" and not the HTTP server handing the request to the component that looks on the filesystem (or in the cache, or in MongoDB, or...) and not finding the resource?

sagichmal 7y ago

> OSI I understand OSI, but it's not a useful model in this circumstance, because it draws no distinction between the HTTP layer and the business logic served over HTTP. The complexities of that interface is what we're talking about. > HTTP status codes reflect the result of the HTTP request itself, not the next application in the chain, if one exists. Let's say I request /robotz.txt and I get 404 Not Found. How do you maintain that 404 is a result of "the HTTP request itself" and not the HTTP server handing the request to the component that looks on the filesystem (or in the cache, or in MongoDB, or...) and not finding the resource?