4 ms·

I've gotten value from HTTP responses in the 300s, 400s, and 500s being handled appropriately by various tools without having to write special RPC logic for tho

• peteretep 5y ago
  That a 404, 301, and 500 being generated by the API vs the web server are very different events and it’s hard to think of where “various tools” handling them the same is the right choice? What examples do you have where it’s the right choice?
  • CBLT 5y ago
    With application servers acting as the authoritative state of a user's current phonecall status, the api client wants a websocket connection to the shard with that user's state. It connects to one and is 302'd to the appropriate shard. It how has a websocket connection directly to the authoritative source to get notified of any state changes. I forget exactly what the scenario was but the request was not being sent with credentials so a 401 was returned, which immediately prompted a retry with the credentials. I'd probably agree that this is covering up an issue that should be fixed.
    • peteretep 5y ago
      How is this a REST API rather than just a regular API being served over HTTP?
    • slver 5y ago
      Curiously the websocket spec says the server may send 30x code during handshake, but the client is "not required to follow it". So in this case you're relying on a specific client's decision more than you're relying on universal interface.
• smt88 5y ago
  HTTP and REST are never reliably supported by clients. For example, many JavaScript clients will throw exceptions for 4xx and 5xx errors, even though handling 4xx errors in the client application is very reasonable. Other clients only treat 5xx as a throwable exception, and some don't throw unless the request fails to hit the HTTP server. Because of these issues, your best bet is to just wrap your HTTP API in a native client library. You certainly can't target a generic HTTP or REST wrapper.
  • jbothma 5y ago
    That's a reflection on a small number of Yet Another Not Invented Here clients, as opposed to the protocol and paradigm
    • smt88 5y ago
      Yes, I agree it is not a reflection of the protocols. It doesn't matter either way -- if you have a standard that no one fully implements, your standard is not practically meaningful.
      • jbothma 5y ago
        I think partially implemented standards are very useful! You can partially implement in a way that provides escape hatches for users, or you can lock them in to your assumption of the right behaviour. That said, I think there are very many http clients that implement enough of the standards to me incredibly rich and in line with the spirit of the protocol. The web for humans and machines is based on http. It can improve, but the standard has quite sufficient support to be called practically meaningful
• deleted 5y ago
  [deleted]
• slver 5y ago
  > I've gotten value from HTTP responses in the 300s, 400s, and 500s being handled appropriately by various tools without having to write special RPC logic for those cases. What am I missing? What exactly is behind this statement? What tools do you have in mind, and what do they do with 400s and 500s? Other than Chrome DevTools coloring the response in red automatically, a big win. /s I've also never seen an API redirect and force a pointless second (and third etc.) roundtrip for the client to get the same exact content. Just because (some) of these codes mean something for a web page and a browser, doesn't mean they're automatically meaningful for a real-world API. That's the critical distinctions, which REST fans refuse to acknowledge.
  • jorge-fundido 5y ago
    Middleware comes to mind (eg caches, proxies, api gateways).