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
- From: Steve K Speicher <sspeiche@us.ibm.com>
- To: Martin P Pain <martinpain@uk.ibm.com>
- Date: Fri, 20 Feb 2015 15:55:59 -0500
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]