Top tip: Call your API a "REST-like API" or "REST-inspired API" and Roy Fielding will only break one of your hands with a lump-hammer when he catches up with you.
@amantinband7 ай бұрын
😆
@dashaenne7 ай бұрын
🤣
@therongovender9471Ай бұрын
At my previous job we had Nancy Modules (yeah i know im old) that implemented hypermedia resources in the response, but we did things a bit differently, there was a 'page setup' initial call that retrieved required resources for that module, and only used that hypermedia links to do requests to the api service
@marna_li7 ай бұрын
Great explanation, Amichai! I knew about hypermedia, but you did teach me some new stuff about the constraints of REST. To my experience people tend to think in terms of controllers and actions (MVC) when about REST. And the use of HTTP methods. And those are just HTTP APIs. The term I use the most nowadays.
@amantinband7 ай бұрын
Right, REST has a slightly different meaning today
@marna_li7 ай бұрын
@@amantinband I would like to build a REST API. I have experimented with HAL as the format for Hypermedia. But it is so cumbersome to consume from strongly-typed languages. It feels wrong. Constructing those Hypermedia APIs take effort. Most are more used to think in entities. But with Hypermedia you have to conceptually separate a resource representation from the entity on the server. And that is a good thing. But it all takes more time it seems to me. That is why some rather don’t do it. There is a tradeoff to everything.
@ahupond7 ай бұрын
I would say HATEOAS didn't become a thing rather because making a dynamic client (capable of interpreting and rendering dynamic list of buttons/actions in the UI, which was the initial idea behind the REST idea) is such an intricate project, expansive, complex and hinders UX/UI creativity. With static clients (buttons roles by convention) you don't need the server to tell you which actions are available, as it would be a waste of resources. It's cheaper, easier to develop and maintain, and more flexible.
@amantinband7 ай бұрын
Yeah definitely
@duznt-xizt7 ай бұрын
Beautifully put 🙏 My sentiments exactly 💯
@PierreThierryKPH7 ай бұрын
Using HATEOAS actually makes the design far more flexible, easy to maintain and evolve.
@duznt-xizt7 ай бұрын
@@PierreThierryKPH Probably the reason why it didn't become a thing in the industry 😜
@PierreThierryKPH7 ай бұрын
@@duznt-xizt the industry has a long history of stubbornly refusing better solutions. People claimed that you can't use C++ because classes will not be fast enough. Then people claimed that you couldn't possibly use garbage collected languages in production because of the performance penalty. Then FP is not usable without a math PhD. The industry is great at having bullshit reasons for not using a great solution.
@geomorillo5 ай бұрын
I will call my apis whatever i like if i say is rest is rest
@m126527 ай бұрын
Isn't sending back 11,000 lines of json a bit excessive. You're assuming it's all needed when chances are not even a couple of hundred lines are require. I mean just coz someone hits your api it doesn't mean they're going to use all the functionality.
@youssefwael87 ай бұрын
When you mentioned the HATEOAS and that REST APIs should expose an endpoint that contains all available actions to be taken, I think of Swagger and its UI. I think Swagger is the modern approach as it complies with the definition of HATEOAS, it exposes an endpoint with all metadata and interfaces. What do you think?
@chilversc7 ай бұрын
That still wouldn't count though as that's developer documentation. Under HATEOS and REST as per the original definition I would be able to change all the routes/URLs on my server and clients would still work without needing to be updated. Maybe one day I wake up, decide I prefer kebab case in my URLs and push out an update. The way we currently write REST APIs your client would break. You would then have to read the new swagger docs and update your client. Under HATEOS that wouldn't be required as your client would get the new links from the server.
@aakashpoojary39687 ай бұрын
Surprisingly, I enjoyed Roy's version of RESTful api. I look at the main URI as an instruction manual for the consumers who can freely consume the api and build on it. I think we can improvise and obviously not send 10k lines of code but definitely some info that can help users to independently build over it.
@ludwintor49867 ай бұрын
isn't open api specification is a same thing but more informative and this just didn't bloat each response with that that "_links" property?
@amantinband7 ай бұрын
No, the premise is having the server dynamically drive the client’s next actions
@Potato-m1l7 ай бұрын
I mean realistically the APIs that truly implement REST are often referred as RESTful APIs, everything else we just typically refer as REST APIs. The distinction already exists, even if diverged from it's original meaning/definition and took on a new name representation.
@PierreThierryKPH7 ай бұрын
People called non hypermedia APIs both REST and Restful. Both terms are used in complete ignorance of the definition of REST.
@nayanchoudhary43537 ай бұрын
As soon as the video started, I tried wiping the white dirt on my screen... Only to realise that it was Amichai's mouse pointer 😂
@NickSteffen7 ай бұрын
Yea, Roy doesn't realize is that no one owns terms and words in a language, not even the person who invented them. It was also a term invented in a different era, when projects had very different goals and requirements. The industry after millions of man hours of determining which components of Roy's original specification work in real modern projects, which don't and adding many others has decided what REST means today. The REST described by Roy Fielding is an anachronism from a bygone era, attempting to steal a valuable term that is well used in the modern world. The world changes, words change, meaning changes, Roy was once right, but he is now wrong about the meaning of REST.
@PierreThierryKPH7 ай бұрын
Actually, most people don't know about the definition of REST and didn't determine what part of REST work. People who understand REST do implement it and reap the benefits of this architecture style. It's as relevant today as it was when it was invented.
@НиколайЗаднепровский-ф2и6 ай бұрын
There is nothing wrong in using some set of concepts only partially and modifying it, but why would you give your new set of concepts the same name? For me the answer is simple: people who started doing that just wanted to sell their APIs as something based on work of respected researcher and creator of internet. And those who followed them did not care enough to look at original source. I'm not against modern "REST" (whatever it is), I just think that it is not right to confuse terms.
@tchial07 ай бұрын
Hahaha! I couldn't resist the title.
@zagoskintoto7 ай бұрын
So RESTless APIs! lol Unrelated question: does anyone know the name of the app he uses to draw on the screen?
@ryan-heath7 ай бұрын
Maybe excalidraw?
@zagoskintoto7 ай бұрын
@@ryan-heath I'm sorry I meant the overlay that allows him to draw anywhere on the screen, like those arrows and boxes with multiple colors he uses in other videos too when showing code
@osmantas3697 ай бұрын
He replied in one of his videos. Presentify which runs on macos.
@zagoskintoto7 ай бұрын
@@osmantas369 Thanks! didn't chat that one
@MichaelBattaglia7 ай бұрын
Just give it a REST!!
@fifty-plus7 ай бұрын
The BFF concept conflated REST with any API you might write removing any meaning from the nomenclature in a technical discussion.
@Petrovich20497 ай бұрын
Someone tell this Roy that OpenAPI specs exist…
@botondvasvari57587 ай бұрын
good morning
@Eirenarch7 ай бұрын
Yeah... this guy doesn't own the language. He came up with the term but in the mind of 99% of people it means http based API that returns JSON and uses the HTTP verbs and URLS to distinguish between different operations and there is nothing he can do about it
@DaveTheRPAGuy7 ай бұрын
Optional constraint makes no sense. 🤣
@PierreThierryKPH7 ай бұрын
People do implementation real REST APIs. Please dont lie to justify your wrong use of the term or your unwillingness to implement REST properly. REST never became something else. It has a clear definition and people either match the definition or they don't.
@yaniv2427 ай бұрын
HATEOS
@psdmaniac7 ай бұрын
I hate religion in development... This is not the Scrum-ish, this is not the REAL REST. Why do people want to use HATEOS in the first place? Most clients (like native mobile aps) will not use it anyway because it gives ONLY complications. If you have Id of the product just call the endpoint without an additional call to "discover" the endpoint. In my opinion, it is better to focus on the working, maintainable product delivered on time, quality and budget not on overengineering and "hyped" solutions.
@amantinband7 ай бұрын
Yep. “tools, not rules”
@PierreThierryKPH7 ай бұрын
Why do people use HATEOAS? Because loose coupling is a huge advantage, because it makes the design more flexible on both sides.
@psdmaniac7 ай бұрын
@@PierreThierryKPHYou are still coupled to data structures returned by endpoints, you still need to have hardcoded urls to "List" endpoints. This is not a lose caupling. In real life everything else is changing more often than urls. If backend side change something there is probability of 99% it will be an entire new endpoints or data structure in existing endpoint and in most cases you still need to change client code to handle this. Hateos is the theory that meets practice and fails 😂
@PierreThierryKPH7 ай бұрын
@@psdmaniac actually you only need one hardcoded URL, it's not often you need several entry points. And I wonder if there's any data backing your theory that every time URLs would change, it means a change so large that the client would need changing too. On the only service that doesn't do HATEOAS in my team, we actually needed to move some actions to a different backend service without changing the protocol and it's a pain. With HATEOAS, it would have been trivial.