6 ms·

HTTP is just a transport for your RPC. It's an implementation detail. At the HTTP layer, the transport was successful, so a 200 is appropriate. A 404 would ind

by mappu 4y ago

HTTP is just a transport for your RPC. It's an implementation detail. At the HTTP layer, the transport was successful, so a 200 is appropriate. A 404 would indicate 'not found' at the transport layer e.g. a bad proxy configuration or you didn't hit the right server at all. You definitely wouldn't confuse it with '${my_widget} not found'.

bigDinosaur 4y ago
This is absolutely counter to everything HTTP is supposed to be used for. I'm not quite sure how to even respond.
- vrnvu 4y ago
  It's a common discussion with HTTP Status Codes. Application vs Transport layer. HTTP status are a mix of both and it can be misleading. A couple of weeks ago there was an interesting post about this topic here in HN.
ahtihn 4y ago
If you serve static content with nginx or any other webserver, you'll get 404 for any file that doesn't exist. Why should '${my_widget} not found' be different?
- number6 4y ago
  The Webserver Servers a file or an endpoint. This file or endpoint have indeed be found. On this layer the transaction was successful. So if you return 404 on this layer you are saying that whatever file or endpoint you searched is not there. If you ask for a resource at an endpoint that does not exist e.g. via an parameter in the url and return 404 it is not clear if the endpoint does not exist e.g. the endpoint.php is missing or the resource you are looking for. Leading to questions like: is the endpoint down, is my internet wonky, did I misspell the name, and business logic related questions: is there no such widget, is the widget out of stock, should I call another endpoint? 404 does not indicate non existence but it indicates an inability to be found by the server. It's a nuance and it only matters when it does and then it bites...
  - 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 ago
      I 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 ago
        I 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.
mike256 4y ago
This is about REST, not RPC.

by mappu 4y ago

bigDinosaur 4y ago

This is absolutely counter to everything HTTP is supposed to be used for. I'm not quite sure how to even respond.

vrnvu 4y ago
It's a common discussion with HTTP Status Codes. Application vs Transport layer. HTTP status are a mix of both and it can be misleading. A couple of weeks ago there was an interesting post about this topic here in HN.

ahtihn 4y ago

If you serve static content with nginx or any other webserver, you'll get 404 for any file that doesn't exist. Why should '${my_widget} not found' be different?

number6 4y ago
The Webserver Servers a file or an endpoint. This file or endpoint have indeed be found. On this layer the transaction was successful. So if you return 404 on this layer you are saying that whatever file or endpoint you searched is not there. If you ask for a resource at an endpoint that does not exist e.g. via an parameter in the url and return 404 it is not clear if the endpoint does not exist e.g. the endpoint.php is missing or the resource you are looking for. Leading to questions like: is the endpoint down, is my internet wonky, did I misspell the name, and business logic related questions: is there no such widget, is the widget out of stock, should I call another endpoint? 404 does not indicate non existence but it indicates an inability to be found by the server. It's a nuance and it only matters when it does and then it bites...
- 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 ago
    I 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 ago
      I 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.

mike256 4y ago

This is about REST, not RPC.