OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: 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

Steve Speicher
IBM Rational Software
OSLC - Lifecycle integration inspired by the web ->

<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":
> 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]