4 ms·

If the API is indeed RESTful, and it complies with the concept that a URI represents an address of a specific resource, then returning 200 even when the resourc

If the API is indeed RESTful, and it complies with the concept that a URI represents an address of a specific resource, then returning 200 even when the resource was not found does not make any sense. The request was not "successful", rather the request failed to find what it was looking for! That said, "single URL APIs that you throw JSON/YAML/whatever at" are not RESTful anyway. For a non-REST API, then it may make sense to return 200 even if something was not found, but it is still not a good idea to just ignore the properties of the upper-level protocol your data is ferried on. > I'm not sure why people insist on spreading their APIs out between the transport and content layer. HTTP is not the transport layer. It's an application protocol meant to convey application data. People spread their API over it because that's how it's supposed to be used. If you're just using HTTP as a means to toss random data between computers, you should consider TCP.

nulltype 11y ago
Maybe you should use TCP instead of HTTP, but there's a number of reasons to use HTTP as basically TCP: * Browsers can't speak TCP natively (oddly enough) * HTTP works through proxies * Most web frameworks do HTTP more easily, same for web servers Of course, the real solution here is probably to use websockets or HTTP/2, since then you get all the advantages of HTTP without the downsides of TCP.
- pdkl95 11y ago
  > (oddly enough) That's by design - allowing arbitrary TCP in a browser is just asking for security and DDoS problems. > HTTP works through proxies So does TCP (SOCKS). > Web servers Using web server wouldn't make sense if you were using straight TCP. The real reasons HTTP is used when plain TCP would be more appropriate are: 1) Lazy/stupid firewalls configured to only allow port 80/443. This leads to everyone doing everything over HTTP, moving the problem and making the firewall much less useful. 2) NAT. When the primary benefit of the internet - where each peer is equivalent in the protocol - cannot be counted on, centralized servers (usually using HTTP because of #1) are used instead of direct TCP.
  - deleted 11y ago
    [deleted]
chromakode 11y ago
On the client side, whether a GET returned a successful (2xx) or error (4xx/5xx) status is observable for cross-origin requests. This can leak information about the user, particularly if you have cookie-authenticated resources that 503 depending on the user's identity (e.g. Facebook 503ing if you're not friends with X). This can be resolved by requiring a CSRF token or fancy header, but that muddles the RESTful semantics. A common solution is to make your public API RESTful and authenticated differently from your browser cookie sessions, and make the private web APIs always return 200.
- TheAndruu 11y ago
  403 would be the proper status if the user was authenticated but forbidden. 503 would imply an error on the server and that the service is unavailable. Here the 403 is appropriate because the user is logged in and trusted to some degree by your system, but isn't allowed to access that URI. If the user were unauthenticated and tried to access the same URL, he should get a 401 for Unauthorized, which is the same response he should get for every URI in your system, thus exposing nothing about your underlying service.
  - nitrogen 11y ago
    GitHub returns 404 instead of 403 to prevent these information leaks.
    - dragonwriter 11y ago
      > GitHub returns 404 instead of 403 to prevent these information leaks. This behavior is explicitly permitted by the standard, FWIW: An origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found). https://tools.ietf.org/html/rfc7231#section-6.5.3 https://tools.ietf.org/html/rfc7231#section-6.5.3
  - chromakode 11y ago
    Ah yes, thank you, that should have been 403. I suspect a 401 would still leak info, as the <img> or <script> tag will let you differentiate between a 200 and other failing status.
deleted 11y ago
[deleted]
johansch 11y ago
Isn't all of that just dogma? See https://news.ycombinator.com/item?id=276687 https://news.ycombinator.com/item?id=276687 for further explanation.
- DomreiRoam 11y ago
  Using an architecture shouldn't be a dogma but a choice. REST is defining a set of constrains that provides a set of benefits. REST emerges because people noticed that the 'Web' was more scalable and robust than other distributed architecture (COBRA, DCOM...). So if your usecases would benefits from caching, discoverability... then you may want to choose REST.
- zeveb 11y ago
  Reading that old thread really makes me realise how perceptions have changed over time. I think more folks understand how useful REST can be, as it provides a standard set of semantics for talking about resources, and that semantics are pretty widely applicable across various situations. In that respect, REST is a lot like relational calculus: certainly not a panacea, certainly not universally-applicable, but an extremely useful way to approach a large number of different problems. And just as one should have to justify why one is not using an RDBMS (and there are a huge number of reasons not to!), one should need to think hard before abandoning REST for RPC.
peteretep 11y ago
> If the API is indeed RESTful, and it complies with the > concept that a URI represents an address of a specific > resource I suspect the maintainers of both of those APIs are doing it right... ;-) More seriously, almost every API I've seen that tries to be (or claims to be) RESTFUL is just somewhat randomly distributing parameters between the URI, headers, and a post body. > HTTP is not the transport layer. It's an application protocol > meant to convey application data Nope, it was definitely designed as a transport layer, which describes meta-data about content going both ways. You can tell it's not a real application protocol because people shoe-horn serialized data structures in both directions.
- e12e 11y ago
  It's a transport protocol for hypertext - but hypertext is a type of application, just a very constrained type of application.
paulddraper 11y ago
Browsers required HTTP.

nulltype 11y ago

Maybe you should use TCP instead of HTTP, but there's a number of reasons to use HTTP as basically TCP: * Browsers can't speak TCP natively (oddly enough) * HTTP works through proxies * Most web frameworks do HTTP more easily, same for web servers Of course, the real solution here is probably to use websockets or HTTP/2, since then you get all the advantages of HTTP without the downsides of TCP.

pdkl95 11y ago
> (oddly enough) That's by design - allowing arbitrary TCP in a browser is just asking for security and DDoS problems. > HTTP works through proxies So does TCP (SOCKS). > Web servers Using web server wouldn't make sense if you were using straight TCP. The real reasons HTTP is used when plain TCP would be more appropriate are: 1) Lazy/stupid firewalls configured to only allow port 80/443. This leads to everyone doing everything over HTTP, moving the problem and making the firewall much less useful. 2) NAT. When the primary benefit of the internet - where each peer is equivalent in the protocol - cannot be counted on, centralized servers (usually using HTTP because of #1) are used instead of direct TCP.
- deleted 11y ago
  [deleted]

chromakode 11y ago

On the client side, whether a GET returned a successful (2xx) or error (4xx/5xx) status is observable for cross-origin requests. This can leak information about the user, particularly if you have cookie-authenticated resources that 503 depending on the user's identity (e.g. Facebook 503ing if you're not friends with X). This can be resolved by requiring a CSRF token or fancy header, but that muddles the RESTful semantics. A common solution is to make your public API RESTful and authenticated differently from your browser cookie sessions, and make the private web APIs always return 200.

TheAndruu 11y ago
403 would be the proper status if the user was authenticated but forbidden. 503 would imply an error on the server and that the service is unavailable. Here the 403 is appropriate because the user is logged in and trusted to some degree by your system, but isn't allowed to access that URI. If the user were unauthenticated and tried to access the same URL, he should get a 401 for Unauthorized, which is the same response he should get for every URI in your system, thus exposing nothing about your underlying service.
- nitrogen 11y ago
  GitHub returns 404 instead of 403 to prevent these information leaks.
  - dragonwriter 11y ago
    > GitHub returns 404 instead of 403 to prevent these information leaks. This behavior is explicitly permitted by the standard, FWIW: An origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found). https://tools.ietf.org/html/rfc7231#section-6.5.3 https://tools.ietf.org/html/rfc7231#section-6.5.3
- chromakode 11y ago
  Ah yes, thank you, that should have been 403. I suspect a 401 would still leak info, as the <img> or <script> tag will let you differentiate between a 200 and other failing status.

deleted 11y ago

[deleted]

johansch 11y ago

Isn't all of that just dogma? See https://news.ycombinator.com/item?id=276687 https://news.ycombinator.com/item?id=276687 for further explanation.

DomreiRoam 11y ago
Using an architecture shouldn't be a dogma but a choice. REST is defining a set of constrains that provides a set of benefits. REST emerges because people noticed that the 'Web' was more scalable and robust than other distributed architecture (COBRA, DCOM...). So if your usecases would benefits from caching, discoverability... then you may want to choose REST.
zeveb 11y ago
Reading that old thread really makes me realise how perceptions have changed over time. I think more folks understand how useful REST can be, as it provides a standard set of semantics for talking about resources, and that semantics are pretty widely applicable across various situations. In that respect, REST is a lot like relational calculus: certainly not a panacea, certainly not universally-applicable, but an extremely useful way to approach a large number of different problems. And just as one should have to justify why one is not using an RDBMS (and there are a huge number of reasons not to!), one should need to think hard before abandoning REST for RPC.

peteretep 11y ago

> If the API is indeed RESTful, and it complies with the > concept that a URI represents an address of a specific > resource I suspect the maintainers of both of those APIs are doing it right... ;-) More seriously, almost every API I've seen that tries to be (or claims to be) RESTFUL is just somewhat randomly distributing parameters between the URI, headers, and a post body. > HTTP is not the transport layer. It's an application protocol > meant to convey application data Nope, it was definitely designed as a transport layer, which describes meta-data about content going both ways. You can tell it's not a real application protocol because people shoe-horn serialized data structures in both directions.

e12e 11y ago
It's a transport protocol for hypertext - but hypertext is a type of application, just a very constrained type of application.

paulddraper 11y ago

Browsers required HTTP.