oslc-core message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Applying OSLC to products that already have a REST/hypermedia API
- From: Martin P Pain <martinpain@uk.ibm.com>
- To: "OASIS OSLC Core TC Discussion List" <oslc-core@lists.oasis-open.org>
- Date: Thu, 19 Feb 2015 16:12:22 +0000
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]