3 ms·
REST is just pure bullshit. Avoid it like a plague. It's a fundamentally flawed model, as it smears the call details across multiple different layers: 1. The
by cyberax 2y ago
REST is just pure bullshit. Avoid it like a plague.
It's a fundamentally flawed model, as it smears the call details across multiple different layers:
1. The URL that contains path and parameters
2. The HTTP headers
3. The request body that can come in multiple shapes and forms (is it a JSON or is it a form?)
As a result, OpenAPI descriptions end up looking horrifying, in the best traditions of the early EJB XML descriptors in Java. And don't get me started on leaky abstractions when you want to use streaming and/or bulk operations.
In comparison, gRPC is _simple_. You declare messages and services, and that's it. There's very little flexibility, the URLs are fixed. A service can receive and return streams of messages.
The major downside of gRPC is its inability to fully run in browsers. But that's fixed by ConnectRPC that adds all the missing infrastructure around the raw gRPC.
Oh, and the protobuf description language is so much more succinct than OpenAPI.
- lordofgibbons 2y agoYeah, I never understood the blind worship of REST. It's just another API style.. and not a good one at that. It is the way it is due to browser limitations. To avoid the complexity you mentioned, one would have to adopt some other tool like OpenAPI and it's code generators. At that point, you might as well use something simpler and plain better: like gRPC.
- voiceofunreason 2y ago"REST is just pure bullshit. Avoid it like a plague." No it isn't. Evidence: I'm reading this in a web browser. "...REST is intended for long-lived network-based applications that span multiple organizations. If you don’t see a need for the constraints, then don’t use them." Bikeshedding the spelling of resource identifiers? Or what "verb" should be used to express specialized domain semantics? Yeah, _that_ is certainly plague bullshit.
- cyberax 2y ago> No it isn't. Evidence: I'm reading this in a web browser. And you might not that this site is _not_ REST-ful. It's certainly HTTP, but not REST. > Bikeshedding the spelling of resource identifiers? Or what "verb" should be used to express specialized domain semantics? Or whether we want to use If-Modified-Since header or explicitly specify the condition in the JSON body. And 6 months later, with some people asking for the latter because their homegrown REST client doesn't support easy header customization on a per-request basis. Or people trying (and failing) to use multipart uploads because the generated Ruby client is not actually correct. There is _way_ too much flexibility in REST (and HTTP in general). And REST in particular adds to this nonsense by abusing the verbs and the path.
- robertlagrant 2y ago> It's certainly HTTP, but not REST. How isn't it RESTful? It's a single entrypoint using content types to tell the client how to interpret it, and with exploratory clues to other content in the website.
- cyberax 2y agoThe "R" letter means "Representational". It requires a certain style of API. E.g. instead of "/item?id=23984792834" you have "/items/comments/23984792834". HN doesn't have this.
- robertlagrant 2y agoRepresentational is to do with being able to deal with different representations of data via a media type[0]. There is stuff about resource identification in ReST, but it's just about being able to address resources directly and permanently rather than the style of the resource identifier: > Traditional hypertext systems [61], which typically operate in a closed or local environment, use unique node or document identifiers that change every time the information changes, relying on link servers to maintain references separately from the content [135]. Since centralized link servers are an anathema to the immense scale and multi-organizational domain requirements of the Web, REST relies instead on the author choosing a resource identifier that best fits the nature of the concept being identified. [0] https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_2_1_2 https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_st...
- mvdtnz 2y ago> "REST is just pure bullshit. Avoid it like a plague." > No it isn't. Evidence: I'm reading this in a web browser. REST is not HTTP endpoints and verbs.