ProgrammerHumor
takeThisWithAGrainOfSalt
Discussion
Really? REST in place of websocket or rpc?
Legends call endpoint every 5 seconds
When you can't make the other end adopt an entirely different protocol, but you need data to be fresh, this is the only way.
Sometimes it is a decent solution
When?
When you can't have websockets.
Or when they could be expensive.
When you submit a task to the backend that completes asynchronously in a more or less defined timeframe.
Imagine you save something but the answer does not come back with a complete result, so you poll in a loop from the frontend asking the backend whether the task is completed to show the confirmation toast.
across security boundaries
When you have no other reasonable option because there's some BS stopping you from implementing a better solution.
Generally speaking, polling is rarely the "best" solution and you should try to avoid it. Polling with HTTP adds way more overhead vs. something like websockets or SSEs.
Hah. Every second, waiting for the video call to be answered… I knew they were cutting costs but not to this degree
Legends never terminate the HTTP response, and use chunked response encoding to provide a server push mechanism that is older than ajax.
Yeah, proxies (CloudFlare) really don’t like this.
For many things, REST is amazing. But websocket definitely has its place, too.
Websocket is great. Most people / companies mess it up though. Found so many vulnerabilities in websocket based apps due to how the same origin policy doesn’t apply to websockets. Probably 90% of apps I’ve reviewed get it wrong.
Definitely, I agree. As I said, take this with a grain of salt ;)
SSE is a lot easier to apply than WebSockets and its very often enough for real-time updates
The api for it is pretty bad though. Can’t even set up request headers using the standard apis, last I tried :/
using the standard apis
An SSE call is just an HTTP call, so setting up the request headers is very simple. Sending a response header on the other hand...
Then again, it’s a really simple protocol, so wrapping it manually is not that hard
setInterval(getDataFromApi, 1)
Polling-based approaches often do work better than websockets. Sure, you're paying for a bunch of pointless HTTP requests, but if you used websockets, you'd also be paying for a persistent connection that is dead most of the time.
Other way at least kind of works not this.
Definitely in place of RPC, but there are some cases where you can't replace WebSockets
Not if you needs to deal with performance in terms of milliseconds
Definitely in place of RPC
No. Different things for different purposes. This meme is just bad.
HTTP persistent connection and push chunks of javascript when needed.
Yes
HATEOS is REST though isn't it?
It's a design pattern for Restful APIs, so yeah, listing it as separate from Rest is stupid
These memes are almost always made by idiots trying to justify their idiocy.
It’s the humor impaired who can’t see the joke
Why? It's something on top of REST, it can be listed separately
Yes. But with a lot more pomp and ceremony. It's not really standardized either, so you kind of have to roll your own.
The fundamental idea about HATEOAS is intriguing. Just send enough metadata alongside your data, so that the GUI can render itself and provide all the actions required. We could develop one generic GUI / Client and it would "magically" work for all HATEOAS backends.
In practice I have yet to see a good implementation of this. HATEOAS moves frontend/UI responsibilities to the backend. E.g. backend now is responsible for providing metadata about all possible actions and navigation on that data. This includes labeling (I18N) those actions.
And those generically rendered UI's are always terrible UX too ...
HATEOAS is for the most part not a good idea. There are a few specific situations, where HATEOAS makes sense. But it should be limited to exactly those use cases within a bigger application.
E.g. I have worked on an application that had a configurable workflow engine in the backend. The frontend would dynamically render the current workflow state, incl. actions for the available transitions into the next workflow state. This way, the frontend could remain "agnostic" about the actual workflow.
Have you tried Htmx?
No practical experience. But I have read about it. If I understand it correctly, with HTMX, backend generates "ready to render" HTML snippets.
If this is correct, it reinforces my point of critique about moving UI responsibility to the backend and tightly couples the backend to a specific frontend.
I can see the value of HTMX for some projects and appreciate that at least they just do "ready to render" HTML snippets. Projects where I have struggled with the entire HATEOAS idea tried to do JSON + metadata. That combination honestly sucked.
Anyways: I currently work on system, where we assume many client implementations. We want the API to be pure data, specified by OpenAPI contracts. We don't want to implement a BFF for each client individually.
The data sent from the server dooesn't have to be the entire render. It can just be structured data in a HTMX (i.e. HTML) format that can be inserted into the front-end, and the front-end can contain all the rendering logic. And that data sent from the back-end can also contain the available HTTP actions that you can perform on that data.
I worked in a project that rolled its own implementation of hateoas and it was beautiful.
Combined with RBAC it was super easy to granularly add features only for users with a given permission - just check whether the resource has a given action defined and if so, then render the front in a way that can take user that route.
However I disliked the fact that - as you said - we did have to roll our own implementation of that. Not that much support from the generic backend frameworks, when I wanted to replicate that in a different, small scale project I had to code it myself and it was much more trouble than it was worth.
Another HATEOS success story chiming in. I didn’t build it, just made some edits to a service that used it, and it was great. I didn’t even really need to worry about it, our FE engineers laid out what should be returned in the contract.
That's how web apps worked before SPA, and that method is still good enough for most apps.
Even more so with few tweaks that avoid full page rendering, like HTMX.
it's not REST, it's a pattern on top of REST
The whole meme is kind of stupid tbh
Yeah, in hindsight I should have put CQRS in there, but that would also rile people up as the CQRS doesn't always expresses itself on the API layer.
You also could have just put RPC instead of gRPC. A lot of CQRS APIs tend to express themselves in an RPC style, but over HTTP with JSON, rather than a specialised protocol like SOAP or gRPC.
Where's my boy SOAP at!?
In its grave, where it belongs, fuck having to know the wsdl, much rather have an openApi definition
get out, get out right now! I saw a job posting a few days ago and SOAP was mentioned...I immediately checked the year on my calendar
back in soft eng networked apps course, we had group project where we needed to make a client-server system using either a SOAP or REST API as its communication method
needless to say my group was forced to use SOAP and I hated it
Has Microsoft come into the modern age or is their ERP still using SOAP?
pulls out baseball bat
Let me know if you see him!
i'd rather use websocket than long polling rest services.
Unless you’re dealing with an event bus, this is just polling on the server side, eh
How does my server tell the client that a new record has appeared…. I know, I’ll just query every 5 seconds! Saving so much complexity here vs a query from an HTTP request from the client! ( I am not hating, I have done this ). Also, when client disconnects, this polling might continue for a bit until the session expires, so it’s also worse. In this one case, I agree REST might be better, but if it’s actually an event stream on the backend too then a WebSocket is so much better in pretty much all scenarios
i don't think you understood my comment. I do prefer websocket over long polling.
Yes, I was just saying that I have seen a lot of times that this is just replacing polling client side for polling server side. In that (IMO common) scenario Websockets are probably overall worse.
I agree with the OP that REST is better there, but with you that in the right architecture: Websockets win.
I too would like to always choose the right solution, but I thought the whole conversation here was about whether the WebSocket is always better than REST, or vice versa.
All chill, my friend, apologies if my comment made no sense
I am that little bird from a webcomic who used to hate GraphQL until it ate the cookie and blushed. Feels so much better to expose the data and let the client grab just what he wants
Yeah, all of those techs have a real use case that REST does poorly.
GraphQL is great for avoiding /resource/id/thatweirdendpointthatfrontendreallyneedssoitcangetaveryspecificsetofdata
Real time communication with rest is bulky AF compared to a websocket. They have their place.
REST and HATEOAS are closely coupled concepts. JSON over HTTP is what the left and right actually are
This meme was created by someone whos on the left side of the spectrum for sure.
Yes. The middle one is me right now. Grpc is 👌.
Guys chill , OP is in college right now
RPC is pretty cool if you just want to build an API for some kind of CQRS application. You can also make it pretty simple by using HTTP rather than gRPC where your commands are POSTs and your queries are GETs. You end up with the simplicity of HTTP without getting caught up in all the HATEOS, REST maturity level, etc.
In my experience REST is cool for CRUD APIs but tends to get in the way when you’re trying to represent a domain with complex business logic and behaviours.
Hey now, WebSockets are bidirectional.
Otherwise agree.
Web sockets and REST are totally different Use-cases. But tbf I think it’s valid to go without GraphQL
Rest: no.
Hammer some bs json api: yes.
We all need to remember students who have bad opinions live on this sub.
Everything is good given a context.
There are also professionals with 12+ YOE who have bad opinions ;)
Just joking with this meme, don't take it too seriously
So you don’t think this, and are trolling?
I am fully aware that all of the technologies from the middle have their legitimate uses where they shine and are great solutions to a specific problem.
However what I am trying to say is that most of the time REST API is a no brainer answer that will be at least good enough.
I think this meme format does not convey that message.
IMO The meme format is saying “people who don’t use REST are but hurt idiots, and using REST is so obvious that dumb people can see it and smart people can see it”
It implies you are a person on the right, when often times posters of this meme format are on the left.
use rs 232 or NCP To send data
Where's my SSE gang?
Would have been funnier if the ends just said “RPC”
Why does he hate OAS?
With age I found gql is just a better default for web apps. Rest mob can fight me all they want, but having the ability to ask for everything you want with a single call beats every rest purist argument.
I HATE HATEOAS
It's kinda in the name isn't it
<cry> in OPC UA
Rest is goated
What is this even supposed to mean? HATEOAS and GraphQL are mutually exclusive.
Hmmm, REST, GraphQL, RPC and other frameworks all have their use cases.
REST is the most common and well understood architectural style and should be the default for modern public APIs
SOAP > REST*
It's a shame it got killed off because all it needed was a half-way decent versioning scheme. Most generators gave you the end point, the full API library, and you didn't have to fight FOSS jank or pay SmartBear a subscription fee.
*This is a senseless argument. I know
Where does binary over udp falls in? I hate the place where I'm working everything is binary over udp
If it were left and right RPC I would have up-voted it.
But I don't have enough salt to swallow this version here.
I'll say it and I'll stand by it: Most so-called "Rest apis" suck.
Just because you put your parameters into the path doesn't make it a rest API! Rest was specifically created for use-cases where you have to do just basic crud actions on connected resources and every path represents a resource. Things like /users/login are not rest. You could do something like a post on /sessions to create a new session or you just accept that your use-case is far away from what rest was made for and use something else.
And it's not even like Rest was particularly good at what it was made for. You pretty much always end up having to request many times the amount of information you actually need, as in rest you always get complete resources, which is a pain when requesting lists and often leads to poor performance.
Rest is built upon HATEOAS
REST, much like the document pretentions of HTML, has mostly outlived its usefulness
Nobody is using REST, everyone is just using HTTP and calling it REST (nor should they, real REST is kind of weird and overengineered TBH)
The problem is, the meaning of REST, as the meaning of agile and devops and whoknowswhat before has changed over time.
Originally by Roy Fielding it was the endpoint using resources (nouns, not verbs) as identifiers with the proper accessors (like HTTP GET to get data, POST to create data...) AND hypermedia/HATEOAS to describe itself and what the client can do with the resource.
Then people started using it and realized that in a SPA world of GUIs and documentations, the hypermedia is too much hassle and dropped it.
Then came somebody else (Martin Fowler) and proclaimed that there were multiple "levels" to REST and created the RMM - the resources, the accessors, the hypermedia all taking you up to "true REST", but by the originators definition, only the third level was actually REST.
So everyone settled for that second, comfortable level and gave it a REST.
(Guess you know that, but for anyone else who was interested, also see https://htmx.org/essays/how-did-rest-come-to-mean-the-opposite-of-rest/ )
Fun read, thanks for sharing
The meaning of REST hasn't gone anywhere for a while. Folks are still making REST calls. People just use REST to dump JSON blobs into a stateless listener because it's a brain dead way to do it with minimal effort. People don't want to make or manage proper SOAP calls for their data or deal with WSDL or have client URLs that have specific RPC calls.
Or don't want to deal with XML. Pick your poison for SOAP.
This. 100%. The primary reason I have updated our systems away from SOAP is I am just sick of working with XMLs.
xml is literally the worst data language i have ever used
Because it's so bad they needed to re-invent the whole XML stack for JSON, like Querying, Validation, Schema, Transformations, etc., right?
I agree that the syntax of XML isn't the best for humans. But people also deal with HTML, which is way worse than XML, and don't complain.
Also if you need to write a lot of XML by hand your doing it wrong anyway. It's meant to be produced and consumed primary by machines. The human readability is just a "nice to have" on top. (And it's actually not even "nice" as proper data formats need to be binary. Text representation is really problematic for a machine!)
I don't see much difference tbh. It took us years to reinvent tooling that came with SOAP, and I'm not sure whether we are there yet. What's the advantage of using json in something that we rarely need to interact with directly ?
Readability. Verifyiability by reading.
A genuine torture technique… pleeeeease no more WSDL’s… I’ll tell you anything!
The web-devs back than didn't get that you never write WSDL, or SOAP messages by hand.
It was meant to be used fully by code-gen.
Than such RPC is just gold! You just define some interfaces, press a button and you have an API ready you can transparently call from the client. All the stuff in between (like describing the interface in WSDL, and exchanging SOAP messages) is don't by some libs.
Life could be so easy. But instead we got brain dead ad hoc JSON-HTTP-APIs which aren't standardized so you have to do everything by hand every time anew. (Of course people tried to get back the comfort of some RPC, using for example OpenAPI, but this stuff never worked properly. It's a complete mess. Especially compared to proper RPC.)
To be fair, we see some GRPC and such stuff here and there. But the masses are still on JSON-HTTP-APIs.
r/Angryupvote
Yeah, we should give them a REST. Same for "Agile" and "DevOps". No point arguing about it anymore.
Wasn't RMM (Richardson Maturity Model) created by Leonard Richardson? Just asking, as I've always believed Martin Fowler only described it in a pretty concise and approachable manner.
Exactly. REST is not "http+json".
We use REST every day. It's literally the architecture of the internet. Everytime you make a website with links that connect pages and resources-- you have made a REST API!
Fielding was literally just describing his work at the IETF when creating the standards for the modern web.
- Roy Fielding, "Architectural Styles and the Design of Network-based Software Architectures" (his dissertation where he describes REST)
People tried to shoehorn his model into making simple API's when he was just describing his work on the World Wide Web. He wasn't telling people how to make a web API because they didn't exist yet in the way we know them today. Companies like Amazon pioneered the modern usage of the term.
It's not Fielding's fault that we're judging his work on modern terms that are much different than what he was writing about.
This is not true.
Go on.
I just linked a definitive source (the originator of the term). You just went "nuh uh".
Do you really think that was enough to convince anyone in the world of literally anything?
Try harder.
Nothing in your “definitive source” quote was actually relevant to your claim. If anything, it did more to back up the claim of the person you thought you were refuting: that they aren’t following “REST” patterns, they’re just sending http requests.
“Try harder.”
So, instead of actually attempting to construct an argument, you just decided to extend "nuh uh" to a full paragraph? Without quoting from the source that you said was somehow irrelevant despite the fact that it fully supports my claim that the web architecture is built on REST, your argument basically boils down to "I'm smart and you're dumb!!!!"
We're using REST right now, you nincompoop. We're on the web. The term REST was coined to define the web. Please, try to find a single Roy Fielding quote that would somehow contradict any of these terms. You won't-- because you're just being irascibly incorrect for no reason.
There’s no need to make up for your missed chance to join the high school debate club. You’re just stringing words together lol
I'm sorry that you didn't understand my post. I shouldn't have expected you to be able to google the definition of words. I really wish that you would attempt to have a real argument with me.
Can you just freaking explain how I was wrong about a website being the definitive example of a REST API? Just try your hardest, use your brain for one millisecond, and actually engage in an honest discussion with me. PLEASE.
I don't care about the downvotes. I just want you to try to actually point out which part of my post was incorrect. Just actually say how a web site is not a fundamental example of REST principles. Use your words. I believe in you.
Brevity is the soul of wit. Good lord man. Do you want me to rehash what few words the other guy and I have already said?
What was Roy Fielding talking about in his thesis? How was it not websites? How is a website not an example of REST principles, when that's what he was talking about when he defined the term?
That's where this conversation began, remember? No one has even attempted to pretend like they have proven my remarks as "not true". Yet, here we are, still talking because you're both too lazy to just attempt to make a real argument.
HATEOAS is required by REST and most people don't do it because it's a pointless waste of time.
Yeah, they don't do it with most of their JSON API's-- but they do when they create a website with links. Hypertext is the engine of that application's state. That's just literally how websites work-- with anchor tags. That's what Roy Fielding was describing in his thesis.
Yeah, sorry. I was having a different discussion I think.
No worries!
Using the web is not using a REST architecture.
It's not the "resources", which means in the context of REST HTML pages, that come out of some database, and it's not like a HTML page would end up in some database when you post some web form.
The whole REST idea is ill, as it means to represent the state of the server on the client. That's exactly what you usually don't want! The server state is private, often even secret, and the client gets just some derived surrogate data. Same in the other direction: You're not updating directly the server state when you POST PUT / DELETE some form. You post merely some detached data, which isn't the exact representation of what ends up as state on the server. Especially you're not posting anything that is a "recourse" which the server could deliver, except you do some file upload.
Maybe a "static" blog is REST: What you get in the browser are directly the resources on the server, and when you update one of them you push the whole HTML to the serer. But that's not like any web application works, and it never did like that.
What's the difference?
This article tries to explain it: https://medium.com/@sp00m/rest-over-http-or-why-your-http-api-isnt-restful-94fd92a0e6d4
CRUD or GraphQL, no time to fight over terminology
i think the key difference is the context it gives whenever you talk about it
when people talk about HTTP(s), i think about a proper webpage with HTML, CSS, and JS
when they speak of REST, i think api's with json parameters and responses
am i wrong to make that assumption ? maybe ? who cares ?
as long as everybody involved thinks the same, this nomenclature will hold
Error code 678 - flop
Real REST isn't overengineered in my opinion. Just for some reason, most people seem unable to create a Rest architecture correctly. Or even understand where they failed doing so.
A decoupled client that can "discover" what it needs is a nice idea, but it's just too good to be true. If two applications interact together, they are necessarily coupled, the only question is how. With the common "REST", a given resource is at a given URL and requires given parameters, which is hard-coded.
A true REST will allow you to change the URL... but that's just because you alias it. The client still needs to hardcode the entry point and the process to get the URL. And in practical terms, what's the difference? After all, URL is already a technical identifier, not something you'd need or want to update. Cool URLs don't change, after all.
And if you change the parameters, well, the client now knows in advance it can't make the call instead of trying and getting a 4xx, but it little good that will do. The app can't automagically figure out where to pull any new parameters from.
The flexibility of REST is an illusion. The inflexibility in the pseudo-REST is really the implicit inflexibility of two dumb algorithms trying to work together made explicit. A program needs to, for better or worse, know in advance what services it has access to, because they are the services it was made to access. Everything else is just implementation detail and it's a matter of taste how deep you bury it. I, for one, prefer the shallow grave of pseudo-REST.
I agree that flexibility is an illusion in REST. But that can be for the best IMO.
As it's client oriented, you should only change parameters if the client asks for it and if it has a meaning for the client. In any other cases the server should find a way to abstract the new parameters implicitly without making the client noticing it.
I don't say it's only benefits but I find that staying to rest as it is supposed to be is better than doing pseudo rest and ending having different resources for the same thing and making the client not knowing which one is the good one.
That's why the thing "everybody" does is called RESTful. It's in fact not really REST.
"Real REST", according to Fielding's dissertation, is just a big weirdness, and it's actually questionable that it can be even implemented at all as it's just some very vague concepts.
People were doing HTTP-JSON-"AJAX" APIs long before the term war invented. It was than slapped on, post hoc, onto the HTTP-JSON-"AJAX" APIs to make them look like something PhD worthy, and give that AJAX hack some formally looking underpinning.
💯
The thing about REST is that is not a framework or even a specification. It is an architecture which is somewhat open to interpretation and ultimately unenforceable. So you have major players breaking foundational "rules" and everyone just has to accept it, for example Opensearch's "RESTful" API tells you to attach a body to GET requests.