Personal opinion: a restful endpoint should be /api/orders/123/items?status=active or something along those lines. The path should only refer to resources by name or identifier, since active items returns a subset of a specific resource it should be used in the query string since it is a filter. Also, according to the spec, PUT is for upserting not only updating. PATCH is for updates only
@@Blast-Forward it doesn't have to be... But it is kind of the golden standard... If you have an app that has both a UI and an API, usually you use /api because it's clearer for both developers and the server to route requests to a particular server/resource/location... Usually I have a standalone Spa and a standalone api (or more than one) and I have a reverse proxy in front... /api always goes to the api server while everything else false under the SPA
How would you consume that with client-side rendering? Pick the URLs from the HTML? Then why return HTML in the first place? Just for the sake of being RESTful?
@@Blast-Forward the browser just renders the HTML… like what HTMX does, or Turbo, or the Laravel equivalent, you just swap out part of the page with the new content.
HATEOAS maturity can be achieved by returning HTML instead of JSON. Then the client can parse the response or pick a part that is interesting like the url for example.
Awesome, thanks! I thought you were gonna squeeze it into a 3 minute video but I was pleasantly surprised to see it go on until I checked the video length 😅
HATEOAS should ultimately return hypermedia, not JSON that has to still be parsed on the client (with some additional logic being applied to the data being returned from the server, in some cases (especially on big tech projects)). Ultimately I believe that not responding with a pure declarative HTML response results in most REST APIs being more REST-like, than RESTful. Am I wrong to assume that?
I like the way dealing with state was just handwaved away. Also very much enjoyed the skewer-case, cos using snake_case maps too easily to js varnames.
A REST API typically doesn't return a "page". The 404 page that you see is given from the spa framework itself if your requested path doesn't match one of its predefined paths/patterns. If you make that request through Postman, you'll still likely get the 404 status in response.
@@Dipj01 Oh you mean because this video talks about APIs. I meant when there is no API and you have to scrape a little for example. Would be nice if things work how they are designed to work.
There is no hard rule of thumb. As you can see in the comments, people bend and interpret some of these rules. You can have more than two levels if that's really needed, but it should be on very specific cases. If you have a concrete example we can discuss it.
HTMX was made with the goal of extended HTML to be a complete hypermedia. It abides by the HATEOAS model, and is a simple and effective way to put it into action
There is irregular plurals that can lead non native english speaker on their bottom. I do prefer using singular which in most cases reflect the unity of an entry more than a collection of entries. Also, I kinda disagree with the shortcut on verbs to CRUD : don't close the door on the different design patterns (DDD, TDD, BDD). Then your API preferably must reply what the client asked for with it's content-type header and it could be plain text, REST doesn't means the response should always be a structured format. In the overall, great video !
Your description of HATEOAS is unfortunately flawed. It shouldn't return JSON but should opt purely for HTML. In reality this is the true definition of REstful, html is restful, json isnt. Somehow this got lost in the sauce.
hello I had some ideas but I don't know if these are feasible could you tell me what you think of them New : could you help me understand what results I could get using the api? - first of all creating a GPT, there are canva GPTs and I'm trying to understand if I could get different results by creating my own - then I wanted to know what more result could I obtain using the API in a make scenario? - and finally I was wondering what result I could obtain by creating a Chrome or WordPress extension? my idea is that a robot could scan all the articles on my WordPress site and maybe even my eBay Store then replace all my images so without me having to do it on each of my pages and therefore saving me a lot of time
@@awesome-codingHello can you understand what I am writing, I use google translate but the translations are really very bad and I thought that gpt does exactly the same translations as google
What makes me astonished is how many well-known websites uses 400 as a standard 4xx status code , 400 should be used only when there is a syntax error in the request payload.
You found some of the exceptions :). I usually go with: - /api/v1/auth/login - /api/v1/auth/register - /api/v1/auth/sso/authorize - /api/v1/auth/sso/callback
I like to send 404 instead of 403 because I believe that the client should only be aware of resource that they have access to and 403 shows that the resource exists.
Yes and no:D I understand the benefit of the added security, but think about this scenario: You are working with a 3rd party API and somehow you have your credentials wrong. You make the request and a 404 Not Found is returned. You go back to the documentation and double check the URL. Make the call again - 404 again. It's more likely to thing that there is a bug in the API / documentation than an authentication issue on your part.
Soo does it means laravel frameworks by default is a level 3 REST API? I recently have collaborated with a PHP guy develop an API using laravel, the best practices that he implement based on my understanding in this video, he implement too many slugs, and no single one query params, I think it's confusing for me as Frontend developer, aven though I read the API docs over and over I still didn't get it, what the hell is representating the every /a/b/c ,even on a very simple use case the API just give a response like completely annoying to read,there are many links,pages etc which is not even consumed, he even make an infinite breaking changes that breaks feature that already done, what a horrible PHP guy to collaborate with.
Good video. But for IPC, REST is a half baked piece of cow poo. Maybe one day we'll have a proper binary API protocol that runs alongside HTTP with built in auth, discoverability, param marshalling, autogenerated client stubs, and we won't have to give a dam about the networking internals.
What do you mean the right way to build REST APIs? Yes there is a standard for it, but the purpose of the backend is to make the frontend developer's life easier. It is ok to have a REST API that has an http-only cookie for the browser, and it makes it somehow stateful. Why is it ok? Because it eliminates the need for the client-side to worry about storing the token. It should be stateless in terms of idempotence.
I don't agree. We converted around 10 pages in our product with htmx in just 2 weeks. This would have taken at least a quarter if it was just react + APIs. We actually had time to focus on details and literally everyone asked how these pages are loading faster 😂
@@sandiprai1383 I mentioned the main reasons at the end of the video: - Not as performant / efficient since you are sending over the wire more bytes than necessary. Consider the option that HATEOAS links could have 10-15 entries; - Not widely adopted. Other than some public APIs I worked with in the past, everybody pretty much sticks to level 2. This is especially true in any software that's not open, since you don't really need self discoverable APIs - it' easier for the client to just map to whatever the API is - It is not really an enforced standard, which, in all fairness, it is true about pretty much any architecture / tech since it is very tough to enforce standards on the web :D
I heavily disagree with the content of the video at 4.43. You should never just crerate CRUD endpoints around resources. Instead you should always prefer actions. The backend does highly diverse actions to the resources. The frontend should just tell the backend to do them, by calling an appropriate endpoint.
I totally agree with the use of actions , In my opinion they should be exactly same as it mentioned in the video . HTTP verb + resource name = intended action . The resources should be nouns not actions .
no matter how you do it if its REST its shit most casual systems should use grpc just for sake of compile time type safety and performance they get for free
What makes me astonished is how many well-known websites uses 400 bad request as a standard 4xx status code , 400 should be used only when there is a syntax error in request payload.
Poor Fireship clone.
Yeah, you're right. It's really unfortunate that we receive a well explained top-notch content in a format similar to Fireship. What a disgrace!
pin of shame
@@dotnetapp ya lol
Poor rest-api concept clone.
Poor Talking with English language clone.
Poor Breathing Clone.
Poor Living on the earth Clone.
at least he try to be better day by day
I've been trying to learn API dev for a while now and this is the simplest and most crystal-clear video I've ever stumbled upon. Thanks a lot!
Glad it helped! Thanks for the feedback!
Personal opinion: a restful endpoint should be /api/orders/123/items?status=active or something along those lines. The path should only refer to resources by name or identifier, since active items returns a subset of a specific resource it should be used in the query string since it is a filter. Also, according to the spec, PUT is for upserting not only updating. PATCH is for updates only
Not a personal opinion - that's the industry standard 😅
Why does it have to be /api/... though?
@@Blast-Forward it doesn't have to be... But it is kind of the golden standard... If you have an app that has both a UI and an API, usually you use /api because it's clearer for both developers and the server to route requests to a particular server/resource/location...
Usually I have a standalone Spa and a standalone api (or more than one) and I have a reverse proxy in front... /api always goes to the api server while everything else false under the SPA
@@vexxxG If there is only one client that fits well. Otherwise it can also be a subdomain.
Perfect, that's for saying.
REST APIを正しく構築するためのベストプラクティスが分かりやすくまとめられていて、実際の開発にすぐ活かせそうです。特に設計のポイントやエラーハンドリングの部分が勉強になりました。次回の投稿も楽しみにしています！
The only words that i have heard today that make sense have come from this video...Greatly appreciated.
Wow, thank you!
The classical music in the background was soothing. The content was useful, thanks for sharing.
Fantastic. Concise, useful illustrations, and I like the way you built the concepts up layer by layer. I'm a new subscriber.
Thank you!
Відмінне пояснення і анімація. Заслуговуєш на більше підписників!
Thank you!
7:08 RESTful APIs can return HTML too! Like HTMX suggests, there is nothing more HATETOAS than HTML with its natural support for links and forms etc
9:55 "no accepted standard'
literally HTML is the standard
How would you consume that with client-side rendering?
Pick the URLs from the HTML? Then why return HTML in the first place? Just for the sake of being RESTful?
@@Blast-Forward the browser just renders the HTML… like what HTMX does, or Turbo, or the Laravel equivalent, you just swap out part of the page with the new content.
@@br3nto
But that's not feasible with SPA frameworks. Also, it couples the visual representation, at least the structure, to the underlying data.
HATEOAS maturity can be achieved by returning HTML instead of JSON. Then the client can parse the response or pick a part that is interesting like the url for example.
I recently quit web dev but i still come here watching cuz its interesting, and to like
Thank you! Why did you quit web dev?
@@awesome-coding no creativity, or you follow a specific path or your site will be bad, so yeah
@@cslearn3044 what do you mean by creativity ? Web dev isn't creative
@@cslearn3044 there are a 1000 specific paths , so generally people just use what they like.
@@cslearn3044so what are you doing/pursuing now?
Awesome, thanks! I thought you were gonna squeeze it into a 3 minute video but I was pleasantly surprised to see it go on until I checked the video length 😅
Glad you liked it! I'm planning to shift more towards the 10 minute format.
So much value in this video, amazing!
Awesome content! The knit pickers here can jump in a lake. It’s so hard to find actual production grade info like this! Chapeau 😊
Thank you!
Great video. Just note REST isn’t the *only* option. RPCs can be great for internal API calls
You just guessed what one of my next videos will be about :D
also GraphQL
The representation of backend and frontend developers is spot on
My preference would be to have a query parameter of status = active instead of putting active in the URL
That's fair - a valid alternative.
This was so clear and on point
Next, please do GraphQL
Thank you!
@@awesome-codingGood luck! ❤
Thanks, this was very concise and helpful.
Glad it was helpful!
Would be interesting to see a video on event-driven architecture as well 🙏
Great suggestion! Will plan for something!
Great video! Really clear explanation.
Glad it was helpful!
is HATEOAS backend driving frontend kind of design or these two are different things?
HATEOAS should ultimately return hypermedia, not JSON that has to still be parsed on the client (with some additional logic being applied to the data being returned from the server, in some cases (especially on big tech projects)).
Ultimately I believe that not responding with a pure declarative HTML response results in most REST APIs being more REST-like, than RESTful.
Am I wrong to assume that?
6:15 AFAIK this breaks REST standard. Active should be query paramter on items: GET /api/orders/123/items?filter[status]=active
hello could you help me understand what I could do with certain APIs by using them in GPT customs
It took me 4 years of trial and error, and working with teams to absorb all of this knowledge through osmosis.
thank you, keep up the high quality content
Thanks, will do!
Great lesson! Thank you.
Glad you liked it!
[5:19] why Django has forward slash by default included in routes then?
I guess we would have to ask them :D
I like the way dealing with state was just handwaved away. Also very much enjoyed the skewer-case, cos using snake_case maps too easily to js varnames.
Great video! Thank you!
Could you please make a video describing hateoas more in detail?
Thanks you!
Will post more detailed videos soon.
You know what drives me crazy. websites that serve a 404 page with a 200 status code. What are you doing with your life?
A REST API typically doesn't return a "page". The 404 page that you see is given from the spa framework itself if your requested path doesn't match one of its predefined paths/patterns.
If you make that request through Postman, you'll still likely get the 404 status in response.
@@Dipj01 Oh you mean because this video talks about APIs. I meant when there is no API and you have to scrape a little for example. Would be nice if things work how they are designed to work.
This is the best REST api video on youtube!
Thank you!
Simply Awesome!
Glad you like it!
loved it. made visually and content vise with good quality.
Glad you liked it!
What’s the solution if we need to specify more than two levels in the URL to specify complex relationships?
RPC style naming. Because there's no indirection most of the problems with REST don't exist.
There is no hard rule of thumb. As you can see in the comments, people bend and interpret some of these rules.
You can have more than two levels if that's really needed, but it should be on very specific cases. If you have a concrete example we can discuss it.
9:45 Disadvantages. Why is it still around then? E.g. Spring HATEOAS
People argue it's mostly for theoretical reasons :)
HTMX was made with the goal of extended HTML to be a complete hypermedia. It abides by the HATEOAS model, and is a simple and effective way to put it into action
Great explanation 👏and as always great video
Thank you!
There is irregular plurals that can lead non native english speaker on their bottom. I do prefer using singular which in most cases reflect the unity of an entry more than a collection of entries. Also, I kinda disagree with the shortcut on verbs to CRUD : don't close the door on the different design patterns (DDD, TDD, BDD). Then your API preferably must reply what the client asked for with it's content-type header and it could be plain text, REST doesn't means the response should always be a structured format. In the overall, great video !
Very informative, thanks. 🎉
Glad it was helpful!
which software do you use for editing?
Adobe premiere pro
just building a app based on sessions and ur rest api video is recommended.
absolut legend
very well explained...thanks awesome!!
Thank you!
Your description of HATEOAS is unfortunately flawed. It shouldn't return JSON but should opt purely for HTML.
In reality this is the true definition of REstful, html is restful, json isnt. Somehow this got lost in the sauce.
Awsome video man. Keep up the good work!
hello I had some ideas but I don't know if these are feasible could you tell me what you think of them
New :
could you help me understand what results I could get using the api?
- first of all creating a GPT, there are canva GPTs and I'm trying to understand if I could get different results by creating my own
- then I wanted to know what more result could I obtain using the API in a make scenario?
- and finally I was wondering what result I could obtain by creating a Chrome or WordPress extension?
my idea is that a robot could scan all the articles on my WordPress site and maybe even my eBay Store then replace all my images
so without me having to do it on each of my pages and therefore saving me a lot of time
Ideas?
@awesome-coding I just added some text to my original post
@@awesome-codingHello can you understand what I am writing, I use google translate but the translations are really very bad and I thought that gpt does exactly the same translations as google
@@awesome-coding Hello, I wrote you on instagram
Im the CEO of HTMX and approve!
HATEOAS for everyone!
so much hate but I really fucking liked this video.
The Hub 🥃 lol
Well they have millions of visits each month so it must be up there, right? :))
Great video!
What makes me astonished is how many well-known websites uses 400 as a standard 4xx status code , 400 should be used only when there is a syntax error in the request payload.
then what is the right uri for login,sign in
You found some of the exceptions :).
I usually go with:
- /api/v1/auth/login
- /api/v1/auth/register
- /api/v1/auth/sso/authorize
- /api/v1/auth/sso/callback
this was great
Thank you!
Nice work!
Thank you! Cheers!
Very helpful
Glad it helped!
I like to send 404 instead of 403 because I believe that the client should only be aware of resource that they have access to and 403 shows that the resource exists.
Yes and no:D
I understand the benefit of the added security, but think about this scenario:
You are working with a 3rd party API and somehow you have your credentials wrong. You make the request and a 404 Not Found is returned. You go back to the documentation and double check the URL. Make the call again - 404 again. It's more likely to thing that there is a bug in the API / documentation than an authentication issue on your part.
Don't forget the meta data in the response!
I wonder how to get a job at “The Hub” company
You need to really know the product first.
“must use plurals..”
One second later
“/customer/1/…” 😂
😅🤦♂️
Source material?
yes
Which text to speech app you use?
I thought i was clicking on a fireship vid, feeling sad
hypermedia mentioned
Soo does it means laravel frameworks by default is a level 3 REST API? I recently have collaborated with a PHP guy develop an API using laravel, the best practices that he implement based on my understanding in this video, he implement too many slugs, and no single one query params, I think it's confusing for me as Frontend developer, aven though I read the API docs over and over I still didn't get it, what the hell is representating the every /a/b/c ,even on a very simple use case the API just give a response like completely annoying to read,there are many links,pages etc which is not even consumed, he even make an infinite breaking changes that breaks feature that already done, what a horrible PHP guy to collaborate with.
Good video. But for IPC, REST is a half baked piece of cow poo. Maybe one day we'll have a proper binary API protocol that runs alongside HTTP with built in auth, discoverability, param marshalling, autogenerated client stubs, and we won't have to give a dam about the networking internals.
wow!
hateos is just a simple mpa app made using php or any other backend language
I'm not sure what that means exactly.
@@awesome-codingmpa is multi page application and all mpa most of the time uses hyper mean of all engine shit
only level 3 is REST. everything else is just RPC with specific constraints
Always add versioning
Just use ruby and rails 😏
What do you mean the right way to build REST APIs? Yes there is a standard for it, but the purpose of the backend is to make the frontend developer's life easier.
It is ok to have a REST API that has an http-only cookie for the browser, and it makes it somehow stateful. Why is it ok? Because it eliminates the need for the client-side to worry about storing the token. It should be stateless in terms of idempotence.
🙂
Pro-tip: Never progress to level 3 of the richardson maturity model. HATEOAS has never benefited anyone in the history of HTTP.
I agree - it's more of a theoretical level.
I don't agree. We converted around 10 pages in our product with htmx in just 2 weeks. This would have taken at least a quarter if it was just react + APIs. We actually had time to focus on details and literally everyone asked how these pages are loading faster 😂
Why? Can you explain it
@@sandiprai1383 I mentioned the main reasons at the end of the video:
- Not as performant / efficient since you are sending over the wire more bytes than necessary. Consider the option that HATEOAS links could have 10-15 entries;
- Not widely adopted. Other than some public APIs I worked with in the past, everybody pretty much sticks to level 2. This is especially true in any software that's not open, since you don't really need self discoverable APIs - it' easier for the client to just map to whatever the API is
- It is not really an enforced standard, which, in all fairness, it is true about pretty much any architecture / tech since it is very tough to enforce standards on the web :D
Isn't traditional 'SSR multi page' web applications fulfill this level by default?
The easiest way to build a great Rest API is to provide the same API as DummyJSON 😄
Fair
I heavily disagree with the content of the video at 4.43. You should never just crerate CRUD endpoints around resources. Instead you should always prefer actions. The backend does highly diverse actions to the resources. The frontend should just tell the backend to do them, by calling an appropriate endpoint.
I totally agree with the use of actions , In my opinion they should be exactly same as it mentioned in the video . HTTP verb + resource name = intended action .
The resources should be nouns not actions .
@@bijeesraj007gl
Fireshippilled
I prefer GraphQL for the type safety.
was this a advertisement I seriously can't tell
Avertisment to what? :))
wtf where do you see an ad?
no matter how you do it if its REST its shit
most casual systems should use grpc just for sake of compile time type safety and performance they get for free
`active` should go as a filter param to items resource: orders/123/items?filter=active
/items?active=1
Maybe /items?status=active? In your example one could call 1 a "magic number" :)
@@awesome-coding yes I agree with you
/api/orders/123/items?filter=active
or:
/api/orders/123/items?active=true
Clever video organization, it's great to be able to watch this kind of content for free! 🫶
Glad you enjoyed it! Thanks!
What makes me astonished is how many well-known websites uses 400 bad request as a standard 4xx status code , 400 should be used only when there is a syntax error in request payload.