CRUD

Usage Scenario: Resource Management CRUD Operations

The client is a REST client using HTTP methods to access resources managed by an OSLC AM service provider.

Create resource (via Creation Factory)

1. A REST client obtains the oslc:CreationFactory resource from the oslc:ServiceProvider resource.
2. If the service provider includes a shape then the client can determine exactly what properties are required in the resource creation request, otherwise the client is expected to know what is required in the RDF when creating a new instance of a resource.
3. The authenticated client POSTs a new resource to the creation factory URL. The client is expected to provide the Content-Type header. The service provider is expected to accept content of this type. Standard HTTP content management protocols apply.
   
   If the new resource is in NTriple or Turtle format then an empty URI reference (e.g. <>) is used to represent the URI of the to-be-created resource URI. If RDF/XML is supported then the empty about attribute (e.g. rdf:about="") represents the URI of the to-be-created resource.
4. The service provider creates a new instance of the resource, and returns a 201 Created response with the URI of the new resource in the Location header. The ETag and Last-Modified headers are also expected to be returned.

Create resource (via Delegated UI Creator)

1. An authenticated REST client obtains the oslc:creationDialog resource from the oslc:ServiceProvider resource.
2. An authenticated desktop or web client GETs the creation dialog HTML resource and displays it to the user, using the delegated UI protocol defined in the Core specification.
3. The user interacts with the creation dialog providing the necessary information to create the resource.
4. The service provider responds with a JSON oslc:results object. This object contains the label and URI of each created resource (it is possible for more than one resource to be created).
5. The desktop or web UI client accepts the response and notifies the user.

Retrieve resource instance

1. An authenticated client performs a GET on an OSLC AM resource URI with the OSLC-Core-Version and Accept headers. The core version header should be 3.0(?), and the Accept header should be a type that the service provider provides (e.g. text/turtle, application/ntriples, application/rdf+xml, text/json, …).
2. If the resource exists the service provider returns it in the requested format, along with the ETag header, Last-Modified, and OSLC-Core-Version headers.
3. If the resource is large, the service provider may choose to page the response. The client is prepared to perform additional GETs on the rest of the pages to eventually receive the entire resource. As it is with RDF there is no expected ordering or priority of properties. The service provider includes

Update a resource

1. The REST client GETs the full representation of a resource (see Retrieve resource, and notes the ETag header.
2. The REST client PUTs back the resource with the updated properties, and the value of the ETag in an If-Match header.
3. The service provider responds with a 200 OK, and an updated ETag value in a response header.

Delete a resource

1. The REST client obtains the resource’s current ETag value, either by getting its full representation of a resource (see Retrieve resource, and the ETag header, or just gets the headers with a HEAD request.
2. The REST client DELETEs the resource with the value of the ETag in an If-Match header.
3. The service provider responds with a 200 OK.
4. If the ETag does not match the current value, then the service provider returns with a 409 Conflict, or 412 Precondition Failed.