The Right Way To Build REST APIs
Вставка
- Опубліковано 5 лип 2024
- Best Practices for building REST APIs.
💬 Topics:
1. Richardson Maturity Model;
2. Stateless vs Stateful APIs;
3. Define correct REST Endpoints;
4. REST Endpoints responses;
5. Plain Text vs JSON vs XML vs YAML;
6. Handling exceptions in APIs;
7. REST API versioning;
8. HATEOAS
9. The HTTP protocol;
🥇 Become a Member - / @awesome-coding
✉️ Join the Newsletter - newsletter.awesome.club/
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.
@RoelCagantas someone's mad
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 😅
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!
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
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?
You know what drives me crazy. websites that serve a 404 page with a 200 status code. What are you doing with your life?
Are those sites built with a framework or library like React? For SPA’s, the router is responsible for rendering your app, nothing else, and without it your app won’t be found/initiated/rendered. Netlify, Nginx, Vercel etc. all need to defer that 404 responsibility (all routing responsibility), to the SPA’s router - and the only way to do that, is to tell the service to always return a 200, and redirect to your project’s entry point (index) so the router can load and do its thing.
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 Yeah, that’s what I’m saying. His condition can only happen on the front-end, with a SPA - and there’s a reason why that I was trying to explain.
@@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.
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.
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!
The only words that i have heard today that make sense have come from this video...Greatly appreciated.
Wow, thank you!
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.
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?
very well explained...thanks awesome!!
Thank you!
Great video! Really clear explanation.
Glad it was helpful!
Great video!
Simply Awesome!
Glad you like it!
thank you, keep up the high quality content
Thanks, will do!
The Hub 🥃 lol
Well they have millions of visits each month so it must be up there, right? :))
Very informative, thanks. 🎉
Glad it was helpful!
loved it. made visually and content vise with good quality.
Glad you liked it!
Nice work!
Thank you! Cheers!
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.
Great explanation 👏and as always great video
Thank you!
This was so clear and on point
Next, please do GraphQL
Thank you!
@@awesome-codingGood luck! ❤
this was great
Thank you!
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.
I wonder how to get a job at “The Hub” company
You need to really know the product first.
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.
Very helpful
Glad it helped!
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.
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.
Great video! Thank you!
Could you please make a video describing hateoas more in detail?
Thanks you!
Will post more detailed videos soon.
It took me 4 years of trial and error, and working with teams to absorb all of this knowledge through osmosis.
is HATEOAS backend driving frontend kind of design or these two are different things?
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
so much hate but I really fucking liked this video.
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.
Im the CEO of HTMX and approve!
HATEOAS for everyone!
which software do you use for editing?
Adobe premiere pro
wow!
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
This is the best REST api video on youtube!
Thank you!
Don't forget the meta data in the response!
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.
Source material?
[5:19] why Django has forward slash by default included in routes then?
I guess we would have to ask them :D
hypermedia mentioned
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
Always add versioning
🙂
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.
only level 3 is REST. everything else is just RPC with specific constraints
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.
Which text to speech app you use?
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
was this a advertisement I seriously can't tell
Avertisment to what? :))
Fireshippilled
The easiest way to build a great Rest API is to provide the same API as DummyJSON 😄
Fair
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?
I prefer GraphQL for the type safety.
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
/items?active=1
Maybe /items?status=active? In your example one could call 1 a "magic number" :)
@@awesome-coding yes I agree with you
`active` should go as a filter param to items resource: orders/123/items?filter=active
/api/orders/123/items?filter=active
or:
/api/orders/123/items?active=true