Thursday, 15 August 2013

Generating a HATEOAS client library

Generating a HATEOAS client library

Suppose I have a RESTful API for managing orders which uses HAL to
facilitate HATEOAS:
GET /orders/2
{
"_links": {
"self": "/orders/2",
"items": "/orders/2/items"
},
"subtotal": 30.0,
"shipped": false
}
I want to write my client (application) using a set of interfaces so that,
assuming that implementations of these interfaces are DI-d/built by DI-d
factories, etc., I don't really (want to) have to care that they're backed
by my RESTful API. As an example (pseudo C#/Java):
public interface Order {
public void addItem(Item item);
public float getSubtotal();
public boolean getShipped();
}
Order order = ...;
Item item = ...;
order.addItem(item);
...(order.getSubtotal())...;
My question is: can I/does it make sense to generate implementations of
the Order/Item interface from the API? By this I mean in a manner similar
to that offered with C#/web services which export WSDLs.
I've been thinking about implementing OPTIONS for resources such as
/orders and /orders/{id} so that I'd effectively have a HATEOAS API for
traversing the schema of the API:
GET /orders/* (I'd need a suitable wildcard of course)
{
"_links": {
"addItem": {
"href": "/orders/{id}/items",
"templated": true,
"type": "method"
}
}
}
Of course I could make this part of the _links object returned with any
given resource (/orders/2, for instance) but that precludes static code
generation.
I'm wondering if there's a sensible way to encapsulate the fact that if a
particular link is provided, the related action should be
available/performed, otherwise not.
Note: In case it matters, I'm actually working in JavaScript (specifically
with AngularJS). However, I'd still like to write my application using a
set of conceptual interfaces/contracts.

No comments:

Post a Comment