Content Item

From n² wiki

Nearby: Platform API

URI Pattern

http://api.talis.com/stores/{store}/items/{id}

Allowed Methods

HEAD,GET,PUT,DELETE

This URI represents an item held in a store's Contentbox

[edit] GET

GETs to a content item require the basic search capability.

The response to a GET request will include an etag HTTP header which may be used to perform conditional PUTs and DELETEs

Note: If a GET is issued to an item that does not exist in the contentbox the Platform checks to see if it has any metadata about the requested item in the store's Metabox. If so the response will be an RDF/XML document containing any triples found in the contentbox that have the requested item as a subject. In the near futire this behaviour will be refined to return a 303 response code redirecting the request to the RDF description. See jira:API-135 for more details.

[edit] PUT

PUTs to a content item require the full update capability.

A user with full update capability is able to issue a PUT on any URI that is prefixed with a store's content box URI. The body of the PUT request will be added to the content box and processed in the usual way. The URI put to must not contain a query string and must be a valid URI according to the HTTP URI specification.

As examples, the following URIs are valid:

  http://api.talis.com/stores/{storename}/items/1
  http://api.talis.com/stores/{storename}/items/foo
  http://api.talis.com/stores/{storename}/items/-----blah-----
  http://api.talis.com/stores/{storename}/items/index.html
  http://api.talis.com/stores/{storename}/items/1/2/3/4/5

However, the following are not allowed:

  http://api.talis.com/stores/{storename}/foo 
  http://api.talis.com/stores/{storename}/items?foo=1

PUT can be used to replace an item or create a new one. Any triples about the item in the metabox will be removed and replaced by any extracted from the new item.

The client can use the if-match and if-none-match HTTP headers to perform a conditional update. This can prevent the "lost update" problem where a client gets an item and updates it inadvertently overwriting another client's changes that were made between the GET and the PUT. The effects of using these headers is shown in the following table:

Header	Value	Action
if-match	an etag	The PUT will succeed only if an item with the supplied etag is stored at the URI
if-match	*	The PUT will succeed only if any item is stored at the URI
if-none-match	an etag	The PUT will succeed only if an item with a different etag to that supplied is stored at the URI
if-none-match	*	The PUT will succeed only if no item is stored at the URI

[edit] DELETE

DELETEs to a content item require the full update capability.

DELETE can be used to remove an item. Any triples about it in the metabox will also be removed.

The client can use the if-match and if-none-match HTTP headers to perform a conditional delete. This can prevent the "lost update" problem where a client gets an item and updates it inadvertently overwriting another client's changes that were made between the GET and the DELETE. The effects of using these headers is shown in the following table:

Header	Value	Action
if-match	an etag	The DELETE will succeed only if an item with the supplied etag is stored at the URI
if-match	*	The DELETE will succeed only if any item is stored at the URI
if-none-match	an etag	The DELETE will succeed only if an item with a different etag to that supplied is stored at the URI
if-none-match	*	The DELETE will succeed only if no item is stored at the URI