6 ms·
You're talking about implementation details on thw server side. Why should the client care about that? Why should the error code for /product/foo/thumbnails/12
by ahtihn 4y ago
You're talking about implementation details on thw server side. Why should the client care about that?
Why should the error code for /product/foo/thumbnails/123.jpg be different if served with nginx serving a static file or an application server that dynamically generates it based on the product id?
- number6 4y agoI make a distinction between the file and the endpoint. While 123.jpg can be found or not the thumbnails/123/ API Endpoint has two parts, the Call and the Argument: 123. To be honest... my argument unraveled in my head while writing - yes you have a point there. So I just can say that 404 is unhelpful because it's unspecific.
- mappu 4y agoI think it's about the route. For a `thumbnails/123/` endpoint, the parameters are specified in the route. You're encoding more information in the HTTP level, so encoding the error in the HTTP level as well is reasonable, you can definitely have a 404 response if there's no 123 image present. But if the route is ID-agnostic, like `/cgi-bin/generate_thumbnails.pl` or `/api/json_rpc.php` then you could justify a 200 OK that the endpoint itself was found, regardless of the parameters. In this design the RPC is definitely above the HTTP level.