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

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

<> wrote on 02/19/2015
11:12:22 AM:

> From: Martin P Pain <>

> To: "OASIS OSLC Core TC Discussion List"
<>

> Date: 02/19/2015 11:12 AM

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

> Sent by: <>

> 

> 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