# Why Doesn't OSLC Fully Comply with Roy Fielding's HTTP Semantics? **URL:** \ **Category:** OSLC\ **Created:** [April 23, 2020, 8:39pm UTC](https://forum.open-services.net/t/why-doesnt-oslc-fully-comply-with-roy-fieldings-http-semantics/371 "2020-04-23T20:39:45Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![sgarfinkel](https://forum.open-services.net/letter_avatar_proxy/v4/letter/s/5daacb/32.png) [@sgarfinkel](https://forum.open-services.net/u/sgarfinkel)\ **Post date:** [April 23, 2020, 8:39pm UTC](https://forum.open-services.net/t/why-doesnt-oslc-fully-comply-with-roy-fieldings-http-semantics/371/1 "2020-04-23T20:39:45Z")
Here’s Fielding’s RFC: [RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](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. ---
**Author:** ![isccarrasco](https://forum.open-services.net/user_avatar/forum.open-services.net/isccarrasco/32/220_2.png) [@isccarrasco](https://forum.open-services.net/u/isccarrasco)\ **Post date:** [April 24, 2020, 10:32pm UTC](https://forum.open-services.net/t/why-doesnt-oslc-fully-comply-with-roy-fieldings-http-semantics/371/2 "2020-04-24T22:32:33Z")
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](https://tools.ietf.org/html/rfc7231#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](https://restfulapi.net/rest-put-vs-post/) is another comparative chart between `POST` and `PUT` In the OSLC specification a [Creation Factory](https://archive.open-services.net/bin/view/Main/OslcCoreSpecification.html#Creation_Factories) 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. ---
**Author:** ![sgarfinkel](https://forum.open-services.net/letter_avatar_proxy/v4/letter/s/5daacb/32.png) [@sgarfinkel](https://forum.open-services.net/u/sgarfinkel)\ **Post date:** [April 29, 2020, 3:34pm UTC](https://forum.open-services.net/t/why-doesnt-oslc-fully-comply-with-roy-fieldings-http-semantics/371/3 "2020-04-29T15:34:46Z")
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! ---
**Author:** ![andrew](https://forum.open-services.net/user_avatar/forum.open-services.net/andrew/32/28_2.png) [@andrew](https://forum.open-services.net/u/andrew)\ **Post date:** [April 29, 2020, 7:54pm UTC](https://forum.open-services.net/t/why-doesnt-oslc-fully-comply-with-roy-fieldings-http-semantics/371/4 "2020-04-29T19:54:44Z")
[https://www.w3.org/TR/ld-bp/#uri-design-principles](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. ---
**Author:** ![jad](https://forum.open-services.net/user_avatar/forum.open-services.net/jad/32/42_2.png) [@jad](https://forum.open-services.net/u/jad)\ **Post date:** [April 30, 2020, 8:00am UTC](https://forum.open-services.net/t/why-doesnt-oslc-fully-comply-with-roy-fieldings-http-semantics/371/5 "2020-04-30T08:00:47Z")
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](https://oslc.github.io/developing-oslc-applications/eclipse_lyo/lyo-designer.html) 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.