Why Doesn't OSLC Fully Comply with Roy Fielding's HTTP Semantics?

#1

Here’s Fielding’s RFC: https://tools.ietf.org/html/rfc7231

The OSLC Spec largely complies with the defined semantics:

  • GET on a resource returns the resource
  • DELETE on a resource deletes it
  • PUT of a modified resource is an idempotent update (I think), but as far as I can tell does not create a new one?

So that’s where the spec starts to diverge. Instead of PUTting a new resource, you instead have to leverage a separate URI to create a new one. Why?

Separately, why are queries a separate endpoint instead of being encoded in the query string for a resource or as the body of a post?

Basically, I’m just confused here and hoping someone might be able to provide some insight here.

#2

Hello @sgarfinkel.

Regarding to the Fielding’s specification you mentioned there is another METHOD for creating resources, the POST which in turn is not idempotent, you could find it in the page 25 of the RFC.

As far as the POST method is concerned you do not need an ID for the resource you want to create, the PUT method it does.

Here is another comparative chart between POST and PUT

In the OSLC specification a Creation Factory is implemented for using the POST method to create the resource and return the created ID (URI).

Hopefully this helps to clarify a bit more your doubts.

Regards!

– Mario.

2 Likes
#3

Hi Mario,

My confusion is not really on the methods and how they are implemented in OSLC, but rather how they are implemented with respect to a particular path.

Given /foo/{id}, per Fielding:

  1. GET on /foo returns all foo objects. A set of query string parameters can be used to filter the underlying data set.
  2. GET on /foo/{id} returns the foo with the given id.
  3. DELETE on /foo/{id} deletes the foo with the given id
  4. POST on /foo updates a foo, the underlying semantics (create a new one? update in-place, etc.) are defined by the application, not by the specification.
  5. PUT /foo/{id} creates a new foo with the given id replacing any existing one.

I am specifically confused about why OSLC implements completely different semantics RE: 1, 4, and 5. I’ll unpack:

For 1: OSLC defines Query Capabilities, which are completely independent endpoints for filtering the data set. Why doesn’t OSLC just use query string parameters?

For 4 and 5: Creation Factories could be implemented as POST/PUT at the corresponding /foo/{id} endpoints, however OSLC says a separate endpoint must be defined to serve these.

Hope that clarifies the confusion!

#4

https://www.w3.org/TR/ld-bp/#uri-design-principles encourages URI opacity, i.e. not relying on URI structure and instead only looking at the semantics of the RDF properties to judge where links point to.

#5

While OSLC does not directly implements the semantics you suggest under 1 and 4, it does not hinder it either.

  1. There is nothing in the standard that hinders you from specifying GET /foo as the query endpoint.
  2. There is nothing in the standard that hinders you from specifying POST /foo as the creation endpoint.

Interesting enough, only until recently LyoDesigner defaulted to exactly your suggestion when generating server code. But then recently moved away from that. Why? It was more flexible to detach the URIs of resources, from the services of the server.

Concerning 5, It’s not a likely scenario that the client calling for the creation of a resource can dictate the id of the resource. This should be really left to the server to decide.

Finally, remember that OSLC promotes the use of Service discovery to find your endpoints, as opposed to make any assumptions on the URLs.