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

[Steve K Speicher <sspeiche@us.ibm.com>]

I agree and shared some thinking on this
[1], which expands on Martin Fowler's work.  I also look like it as
OSLC provides additional capabilities on existing REST APIs, so it should
naturally layer these capabilities on -- when needed.

[1]: http://stevespeicher.blogspot.com/2014/12/web-api-maturity-model.html

Thanks,
Steve Speicher
IBM Rational Software
OSLC - Lifecycle integration inspired by the web -> http://open-services.net

<oslc-core@lists.oasis-open.org> wrote on 02/19/2015
11:12:22 AM:

> From: Martin P Pain <martinpain@uk.ibm.com>
> To: "OASIS OSLC Core TC Discussion List"
<oslc-core@lists.oasis-open.org>
> Date: 02/19/2015 11:12 AM
> Subject: [oslc-core] Applying OSLC to products
that already have a REST/hypermedia API
> Sent by: <oslc-core@lists.oasis-open.org>
> 
> 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