Because everything is not a “resource” on our drone platform, we were tired of maintaining our RESTFul API.
I’ll talk about the pros and cons of designing an API following the action pattern. Here are a few (- is a con, + is a pro) :
– it is not usual… (we have to deal with developer frustration :)
– there are much more API routes than for RESTFul API (/pet becomes /create-pet, /delete-pet, /update-pet…)
+ it is easier to apply a specific authorization policy on an action (no need to check the content of the request : the route is allowed or not)
+ it’s easier to add a new feature, and not trying to make it fit to the RESTFul principles (especially if more than one resource is involved in this operation)
+ we don’t have to remember all the RESTFul-related status codes. If it’s ok, it’s 200. For every other applicative error, we use the same status code, and maintain a list of error keywords.
+ no more PUT, DEL, UPDATE headaches : we use only POST and GET
+ and more ;)
High impact blog posts and eBooks on API business models, and tech advice
Connect with market leading platform creators at our events
Join a helpful community of API practitioners
Can't make it to the event? Signup to the Nordic APIs newsletter for quality content. High
impact blog posts on API business models and tech advice.
Become a part of the world’s largest community of API practitioners and enthusiasts. Share your insights on the blog, speak at an event or exhibit at our conferences and create new business relationships with decision makers and top influencers responsible for API solutions.