In comparing REST [api] structure with a OO model, I see these similarities:
Both:
Are data oriented
- REST = Resources
- OO = Objects
Surround operation around data
- REST = surround VERBS (Get, Post, ...) around resources
- OO = promote operation around objects by encapsulation
However, good OO practices do not always stand on REST apis when trying to apply the facade pattern for instance: in REST, you do not have 1 controller to handle all requests AND you do not hide internal object complexity.
On the contrary, REST promotes resources publishing of all relations with a resource and other on at least two forms:
via resource hierarchy relations (A contact of id 43 is composed of an address 453) :
/api/contacts/43/addresses/453
via links in a REST json response:
>> GET /api/contacts/43 << HTTP Response { id: 43, ... addresses: [{ id: 453, ... }], links: [{ favoriteAddress: { id: 453 } }] }
Coming back to OO, the facade design pattern respect a Low Coupling
between an objectA and its 'objectB client' and High Cohesion
for this objectA and its internal object composition (objectC, objectD). With the objectA interface, this allow a developer to limit impact on objectB of the objectA internal changes (in objectC and objectD), as long as the objectA api (operations) are still respected.
In REST, the data (resource), the relations (links), and the behavior (verbs) are exploded in different elements and available to the web.
Playing with REST, I always have an impact on code changes between my client and server: Because I have High Coupling
between my Backbone.js
requests and Low Cohesion
between resources.
I never figured out how to let my Backbone.js javascript application
deal with "REST resources and features" discovery promoted by REST links. I understand that the WWW is meant to be served by multi servers, and that the OO elements had to be exploded to be serviced by many hosts in there, but for a simple scenario like "saving" a page showing a contact with its addresses, I end up with:
GET /api/contacts/43?embed=(addresses) [save button pressed] PUT /api/contacts/43 PUT /api/contacts/43/addresses/453
which lead me to move the saving action atomic transactional responsibility on the browsers applications (since two resources can be addressed separately).
With this in mind, if I cannot simplify my development (Facade design patterns not applicable), and if I bring more complexity to my client (handling transactional atomic save), where is the benefit of being RESTful ?
PUT /api/contacts/43
cascade the updates to inner objects? I had a lot of APIs designed like this (master URL reads / creates / updates the "whole" and sub urls updates the pieces). Just make sure that you don't update address when no changes are required (for performance reasons).