[deleted]
Most RESTful APIs aren't really RESTful
481–490 of 580 posts
Re: Most RESTful APIs aren't really RESTful
#482Earlier quoted context omitted.
When I realized that I was calling openapi-generator to create client side call stubs on non-small service oriented project, I started missing J2EE EJB. And it takes a lot to miss EJB. I'd like to ask seasoned devs and engineers here. Is it the normal industry-wide blind spot where people still crave for and are happy creating 12 different description of the same things across remote, client, unit tests, e2e tests, o…
I've seen some systems with a lot of pieces where teams have attempted to avoid repetition and arranged to use a single source of schema truth to generate various other parts automatically, and it was generally more brittle and harder to maintain due to different parts of the pipeline owned by different teams, and operated on different schedules. Furthermore it became hard to onboard to these environments and figure…
> I've seen some systems with a lot of pieces where teams have attempted to avoid repetition and arranged to use a single source of schema truth to generate various other parts automatically, and it was generally more brittle and harder to maintain due to different parts of the pipeline owned by different teams, and operated on different schedules.
I'm not sure what would lead to this setup. For years there are frameworks that support generating their own OpenAPI spec, and even API gateways that not only take that OpenAPI spec as input for their routing configuration but also support exporting it's own.
Re: Most RESTful APIs aren't really RESTful
#483Earlier quoted context omitted.
What RPC mechanisms, in your opinion, are the most ergonomic and why? (I have been offering REST’ish and gRPC in software I write for many years now. With the REST’ish api generated from the gRPC APIs. I’m leaning towards dropping REST and only offering gRPC. Mostly because the generated clients are so ugly)
Just use gRPC or ConnectRPC (which is basically gRPC but over regular HTTP). It's simple and rigid. REST is just too "floppy", there are too many ways to do things. You can transfer data as a part of the path, as query parameters, as POST fields (in multiple encodings!), as multipart forms, as streaming data, etc.
> REST is just too "floppy", there are too many ways to do things.
I think there is some degree of confusion in your reply. You're trying to compare a framework with an architecture style. It's like comparing, say, OData with rpc-over-HTTP.
Re: Most RESTful APIs aren't really RESTful
#484Earlier quoted context omitted.
I'd agree with your great-grandparent post... people get stuff done because of that. There has been no lack of heavyweight, pre-declare everything, code-generating, highly structured, prescriptive standards that sloppyREST has casually dispatched (pun fully intended) in the real world. After some 30+ years of highly prescriptive RPC mechanisms, at some point it becomes time to stop waiting for those things to unseat…
> There has been no lack of heavyweight, pre-declare everything, code-generating, highly structured, prescriptive standards Care to list them? REST mania started around early 2000-s, and at that time there was only CORBA available as a cross-language portable RPC. Microsoft had DCOM. And that was it. There was almost nothing else. It was so bad that ZeroC priced their ICE suite based on a PERCENTAGE OF GROSS SALES: h…
> Care to list them?
From the top of my head, OData.
Re: Most RESTful APIs aren't really RESTful
#485As far as I know the only actual rest implementation, as Fielding envisioned it, a system where you send the entire representational state of the program with each request is the system Fielding coined the term REST to describe. The WEB.
Has any other system done this? where you send the whole application for each state with each state. project xandu?
I do find it funny how Fielding basically said "hey look at the web, isn't that a weird way to structure a program, lets talk about it." and every one sort of suffered a collective mental brain fart and replied "oh you mean http, got it"
Re: Most RESTful APIs aren't really RESTful
#486Earlier quoted context omitted.
The critical problem with gRPC is that it uses protocol buffers. Which are...terrible. Example: structured schema, but no way to require fields.
Well the competition is REST which doesn’t have a schema or required fields, so not much of a problem.
> Well the competition is REST which doesn’t have a schema or required fields, so not much of a problem.
A vague architecture style is not competition to a concrete framework. At best, you're claiming that the competition to gRPC is rolling your own ad-hoc RPC implementation.
What I expect to happen now is an epiphany. Why do most developers look at tools like gRPC and still decide it's a far better option to roll their own HTTP-based RPC interface? I mean, it's a rational choice for most. Think about that for a moment.
Re: Most RESTful APIs aren't really RESTful
#487I sympathize with the pedantry here and found Fielding's paper to be interesting, but this is a lost battle. When I see "REST API" I can safely assume the following: - The API returns JSON - CRUD actions are mapped to POST/GET/PUT/DELETE - The team constantly bikesheds over correct status codes and at least a few are used contrary to the HTTP spec - There's a decent chance listing endpoints were changed to POST to su…
> - The team constantly bikesheds over correct status codes and at least a few are used contrary to the HTTP spec I really wish people just used 200 status code and put encoded errors in the payloads themselves instead of trying to fuse the transport layer's (which HTTP serves as, in this case) concerns with the application's concerns. Seriously, HTTP does not mandate that e.g. "HTTP/1.1 503 Ooops\r\n\r\n" should be…
The point of status codes is to have a standard that any client can understand. If you have a load balancer, the load balancer can unhealthy backends based on the status code. Similarly if you have some job scheduler or workflow engine that's calling your API, they can execute an appropriate retry strategy based on the status code. The client in most cases does not care about why something failed, only whether it has failed. Being able to tell apart if the failure was due to reverse proxy or database or whatever is the server's concern and the server can always do that with its own custom error codes.
Re: Most RESTful APIs aren't really RESTful
#488I think that all of the unemployed CS grads are rediscovering the "best practices" of the last 40 years in lieu of working. Well, just remember, every HATEOAS-conforming REST API, every chaos-monkey-enabled Microservice-Oriented Architecture, every app that someone spent tone of time hacking down the cyclomatic complexity score, every meticulously UML-diagrammed four-tier architecture, has had their main engineers laid off and replaced by a crack team of junior engineers who adulterated it down to spaghetti code. In the post-AI world, features talk, architecture walks.
Re: Most RESTful APIs aren't really RESTful
#489Re: Most RESTful APIs aren't really RESTful
#490I sympathize with the pedantry here and found Fielding's paper to be interesting, but this is a lost battle. When I see "REST API" I can safely assume the following: - The API returns JSON - CRUD actions are mapped to POST/GET/PUT/DELETE - The team constantly bikesheds over correct status codes and at least a few are used contrary to the HTTP spec - There's a decent chance listing endpoints were changed to POST to su…
Fielding won the war precisely because he was intellectually incoherent and mostly wrong. It's the "worse is better" of the 21st century. RPC systems were notoriously unergonomic and at best marginally successful. See Sun RPC, RMI, DCOM, CORBA, XML-RPC, SOAP, Protocol Buffers, etc. People say it is not RPC but all the time we write some function in Javascript like const getItem = async (itemId) => { ... } which does…
> Fielding won the war
It’s a bit odd to say fielding “won the war” when for years he had a blog pointing out all the APIs doing RPC over HTTP and calling it REST.
He formalised a concept and gave it a snappy name, and then the concept got left behind and the name stolen away from the purpose he created it for.
If that’s what you call victory, I guess Marx can rest easy.