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.
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
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.
@@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.
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.
@@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.
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.
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.
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?
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.
@@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
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.
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.
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.
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.
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
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.
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.
@@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 😂
@@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.
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.
😆
🤣
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
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.
Yeah definitely
Beautifully put 🙏
My sentiments exactly 💯
Using HATEOAS actually makes the design far more flexible, easy to maintain and evolve.
@@PierreThierryKPH Probably the reason why it didn't become a thing in the industry 😜
@@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.
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.
Right, REST has a slightly different meaning today
@@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.
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.
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 😂
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.
People called non hypermedia APIs both REST and Restful. Both terms are used in complete ignorance of the definition of REST.
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?
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.
The BFF concept conflated REST with any API you might write removing any meaning from the nomenclature in a technical discussion.
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?
No, the premise is having the server dynamically drive the client’s next actions
Just give it a REST!!
Hahaha! I couldn't resist the title.
So RESTless APIs! lol
Unrelated question: does anyone know the name of the app he uses to draw on the screen?
Maybe excalidraw?
@@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
He replied in one of his videos.
Presentify which runs on macos.
@@osmantas369 Thanks! didn't chat that one
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.
Someone tell this Roy that OpenAPI specs exist…
I will call my apis whatever i like if i say is rest is rest
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.
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.
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.
good morning
Optional constraint makes no sense. 🤣
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
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.
HATEOS
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.
Yep. “tools, not rules”
Why do people use HATEOAS? Because loose coupling is a huge advantage, because it makes the design more flexible on both sides.
@@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 😂
@@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.