Re: [oslc-core] Applying OSLC to products that already have a REST/hyper

Subject: Re: [oslc-core] Applying OSLC to products that already have a REST/hypermedia API

On Thu, Feb 19, 2015 at 9:12 AM, Martin P Pain <martinpain@uk.ibm.com> wrote:

I've seen on more than one occasion (including my own implementation) the addition of an OSLC API to an existing product resulting in a second REST API being created, more-or-less duplicating the functionality of the first.

I suggest we should encourage implementors NOT to do this, but to overlay OSLC on top of their existing API.
That is, position OSLC to them as a standard way to describe their existing REST resources.

I also suggest we write some guidance on good ways to do this. For example, if they have any resources that already list links to other resources (in plain old XML), then we suggest that if the Accept header contains an RDF media type at a higher priority than application/xml, that they return an LDP Container representation of the same. We should also note that they can have exactly the same HTTP resources as they currently have - even if they currently represent a list of a certain type of resources as a single document containing all its members, they can still do that with OSLC - one HTTP resource containing multiple RDF resources, probably with hash-URIs.

Two things I remember from first reading OSLC specs:
- Whenever there was a new RDF resource required, my assumption was that that would be a different HTTP resource (i.e. instead of being an embedded resource with a hash-URI). (Also I wan't aware of the option to multi-type a single RDF resource, but that applies less here).
- Assuming that this would not be compatible with our existing REST APIs (which was probably more true at 2.0 than now that we're based on LDP).

Also, the Lyo tooling makes it too easy to create an entirely separate API. I'm hoping to be doing some work with Lyo soon, so may experiment to see what layers of abstraction we could have in there to make it easier for implementors to get exactly what they need to plug into their existing API using their existing HTTP server framework.

In some cases, their REST API may be truly incompatible. In which case my personal suggestion would be to decide to migrate towards a hypermedia-based REST API, using OSLC from the start, and deprecate their old one if they can. i.e. move towards "the glory of REST": http://martinfowler.com/articles/richardsonMaturityModel.html#images_richardsonMaturityModel_overview.png

Martin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

oslc-core message