How To Design Amazing REST APIs

[@axelandru9346]

I love the way you are teaching. You are a master !

[@ryan-heath]

Very concise and high quality. Love it!

[@carlcodes8422]

Love this video Amichai, very concise, and a great refresher for everyone!

[@lucaciandrei]

Yes, finally, more.

[@akitoueu]

Nice content!! Can't wait for more of this!

[@xelaksal6690]

Just the best summary of the API best practices! Thanks!

[@DamirSecki]

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!

[@javadmh7827]

Nice Stuff, Keep it going man

[@Whojoo]

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.

[@amantinband]

I talked about it briefly but ended up cutting it due to time constraints

[@stephenyork7318]

Whenever I’ve worked somewhere building REST APIs we always avoided patch, seems to be hard to get right when ultimately PUT is adequate.

[@hakura88]

@@stephenyork7318 we skip patch too, because we don't care that the complete resource is updated

[@Tarabass]

​@@stephenyork7318 in my 25 years of consuming rest api's I never used a patch endpoint. Mostly post, sometimes put..

[@kipfitpal]

​@@stephenyork7318 PATCH isn't at all hard to get right. It's actually more flexible and effective than PUT.

[@bartlomiejuminski]

quality video thank You

[@frimen310]

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

[@diegoborbadev]

Amazing video!

[@averrows]

Amazing video

[@tehmoros]

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.

[@sauliustb]

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..

[@Romlingen]

Very nice video, thanks ! One question. How would you design an advanced search API towards a collection? Where you may have 20+ parameters. Can't put that into the URI.

[@suhutwadiyo]

Mantappp

[@el_nan1]

may I ask what tool are you using for screen annotation? thanks!

[@shahrukhqasim2770]

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?

[@timur2887]

Thank you very much! What app do you use to draw on screen?

[@amantinband]

Presentify. If you’re on windows then ZoomIt is a good alternative

[@timur2887]

@@amantinband thank you!

[@ruekkart]

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?

[@amantinband]

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

[@tchial0]

Finally

[@SerafimMakris]

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.

[@muczos]

Would be nice to have PATCH auth etc ... :

[@tomazkoritnik4072]

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.

[@Eirenarch]

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?