How To Design Amazing REST APIs
HTML-код
- Опубликовано: 26 сен 2024
- Join us on Discord, get the source code (and support the channel 🙂): / amantinband
Clean Architecture Zero to Hero: dometrain.com/...
Domain-Driven Design Zero to Hero: dometrain.com/...
All videos in this playlist: • ASP.NET 8 REST API Tut...
In this video, we'll cover REST API design best practices!
We'll cover everything from URI and resource naming to idempotency, safety, and caching.
Connect with me on 'em socials:
Twitter: / amantinband
LinkedIn: / amantinband
GitHub: github.com/ama...
Check out all my courses on DomeTrain:
dometrain.com/...
Support the channel and get the source code:
/ amantinband
Thanks for watching, don't forget to like & comment & subscribe! ❤️ 💻 
Наука
Very concise and high quality. Love it!
Great video!
But missing important PATCH?
Also woulde be important mentioning authorisation... with userId, where do we handle this (HEADER - usually with bearer token) and how to handle the not authorised response ... but in all, very quick, to the point video... cheers!
Love this video Amichai, very concise, and a great refresher for everyone!
Yes, finally, more.
Nice content!! Can't wait for more of this!
Quick question, why was Patch skipped? I don't think it was mentioned in the video and it is a http method I see being used by several applications by different companies.
I talked about it briefly but ended up cutting it due to time constraints
Whenever I’ve worked somewhere building REST APIs we always avoided patch, seems to be hard to get right when ultimately PUT is adequate.
@@stephenyork7318 we skip patch too, because we don't care that the complete resource is updated
@@stephenyork7318 in my 25 years of consuming rest api's I never used a patch endpoint. Mostly post, sometimes put..
@@stephenyork7318 PATCH isn't at all hard to get right. It's actually more flexible and effective than PUT.
quality video thank You
I'm having doubts about DELETE being idempotent. It's counterpart (POST) is not, as it creates new entities, so unless you're soft-deleting (so basically - updating some deletion timestamp - a common practice) an entity, DELETE will not be idempotent. It will remove the entity on the first request, responding 204 and it should do nothing on the second request (with the same ID), returning 404, as it shows the true state the server is in after the first request. Different states and responses on the first and next requests for the same parameters.
EDIT: For anyone confused, as I was: with DELETE the idempotency is kind of "delayed". The first request changes the server state, as it should, but the subsequent requests with the same ID parameter will not change the server state (as in: will not add/remove entities). In that way DELETE is idempotent. "Soft-delete" should still be treated on the same level as UPDATE request, though.
Amazing video!
Nice overview, but this raises a question for me:
If you should use plural nouns and some level of nesting, given a game, should moves for a player in a specific game then be POSTed to /games/{gameId}/players/{playerId}/moves, or should you do a POST to /moves with a json in the request body?
Functionally both would work, but I can't figure out which is dogmatic..
Amazing video
if someone ask me to explain the http again i will send it this url without subject or title. :D :D
Tnx. Amichai for the content.
Finally
may I ask what tool are you using for screen annotation? thanks!
Thank you very much! What app do you use to draw on screen?
Presentify. If you’re on windows then ZoomIt is a good alternative
@@amantinband thank you!
Is 201 created response okay if we are creating a collection of objects as the location header can only have the route for only one object created with the object's id but not the collection. Can you shed some light on it?
Nice video! I'm thinking about DDD and CQRS integration. Is there any standard similar to REST but for task-oriented interfaces? Something like a task-oriented API? Or is it generally recommended to use just a task-oriented UI but a REST API under the hood?
Not really. Perhaps gRPC is the closest. A common approach is implementing a "RESTful" API, but then converting the request internally to a command/query which is what's used to invoke the underlying task
Would be nice to have PATCH auth etc ... :
With REST API design I always ask myself "why oh why?". Why using it, when there are so much simpler solutions. I use JsonRPC and is so much simpler, so much easier to understand and so much more natural to use. So, why? Don't get me wrong, one can build really bad APIs with RPC, therefore the API design is VERY important. I usually try to design APIs where a RPC request always targets an object. It's like calling an action on an object from the domain model.
I think that HTTP is abused in REST and that API design is adapted to fit to HTTP instead of adapting API design to our domain. There is simply too much mapping needed between domain code and API code in REST and requires lots of documentation to understand it. We developers have more than enough complexity elsewhere to deal with.
Also all mentioned for REST apply also to RPC: nesting, versioning, idempotency, even HATEOAS.
I disagree with the /products/{productId}/reviews/{reviewId} URL. If you have reviewId it goes under /reviews/{reviewId}. Why make the user provide 2 different IDs? What happens if they mismatch? Why allow a situation where we need to answer these questions at all?
0:57 URI
3:53 GET method
7:10 POST method
8:29 PUT method
11:19 DELETE method
12:29 Idempotency of methods
15:13 Safety of methods
16:30 Status codes
Mantappp
Just the best summary of the API best practices! Thanks!