What URL endpoint do you assign to each of your “resources”? Yeah it’s easy, but it has to be done anyway. How do you map the precise functions above, to a handful of CRUD operations? Is sending the activation reminder email an update on a “must_send_activation_reminder_email” attribute? Or the creation of a “activation_reminder_email resource”? Is it sensible to use DELETE for cancelSubscription() if the subscription remains alive during a grace period, and may be resurrected during that time? How do you split the data tree of getAccountDetails() between endpoints, to respect the data model of REST? Just a vague “RESTful philosophy”, prone to endless metaphysical debates, and as many ugly workarounds. No more standards, no more precise specifications. It is backed by a precise state machine, but the restricted set of available operations keeps users away from nonsensical interactions (like changing the creation date of an Account).Įstimated time to expose this API as a simple RPC service: a few hours. This API is easy to understand, easy to use, and robust. AlreadyExistingUsernameError), and you’re good to go. Just add a properly documented hierarchy of exceptions (InvalidParameterError, MissingParameterError, WorkflowError…), with subclasses to identify important cases (eg. SendActivationReminderEmail(account_id) -> nullĬancelSubscription(subscription_id, reason, immediate=True) -> null createAccount(username, contact_email, password) -> account_idĪddSubscription(account_id, subscription_type) -> subscription_id Here is a small API, with data types removed for readability. What’s the problem with REST?Ī short example is worth a long talk. RPC was dead, the future was RESTful: resources living each on its own URL, and manipulated exclusively through HTTP protocol.įrom then on, every API we had to expose or consume became a new challenge not to say a testimony to insanity. Developer resting after a tough 30mn spent integrating an RPC API.Ī wave of renewal shook the foundations of inter-services communication. Now we were able to expose any set of functions to a wide audience, to servers and to web browsers, with a few decorators and doc updates.Īnd when it came to communicating between our different applications (microservice-style), it was a job for our system administrator software-side, it was almost transparent. Now we were able to robustly connect to any such API, with just a few lines of code. But gradually, we improved them and with a few hundreds lines of additional code, we achieved the dream: support for different dialects (such as Apache-specific XMLRPC extensions), built-in conversion between python exceptions and hierarchical error codes, separate handling of functional and technical errors, auto-retries for the latter, relevant logging and stats before/after requests, thorough validation of input data… ![]() Our first servers and clients for these protocols were pretty basic, limited, fragile. Abstruse WSDLs, incompatible libraries, weird bugs… So whenever we could, we advocated - and used - simple Remote Procedure Call protocols: XMLRPC or JSONRPC. Needless to say, we had our fair share of SOAP Hell. We had to communicate with an increasing number of web services, exposed by older systems or by business partners. ![]() Some years ago, I developed a new information system in a big telecom company. For more in-depth analysis of the original REST, and of HATEOAS, see my follow-up article. ![]() Update : this article mostly deals with the RESTish ecosystem, which now constitutes a major part of webservices. Written by Pascal Chambon, reviewed by Raphaël Gomès
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |