Architecture Management REST API

1.0 SPECIFICATION DRAFT

Introduction

This REST API is designed with some principals in mind. Management of resources is categorized into three areas; factory, query and resource. A factory is where resources are created. In general only a POST method is allowed on a factory URI. Query is where a client gets a collection of resources. Resource URIs are used by clients to get a specific resource, or update and delete it. Resource URIs represent the actual instances of content managed by the AM service provider. Factory and query URIs are typically published in the service specification document.

Resource URIs and Methods

* not all resource types are supported.

** service providers MAY permit the modification of link types

Authentication

OSLC Services use standard web protocols for authentication. OSLC Services can use HTTP Basic Authentication, OAuth or both.

HTTP Basic Authentication

OSLC Services MAY protect resources with HTTP Basic Authentication. OSLC Services that use HTTP Basic Authentication SHOULD do so only via SSL.

OAuth Authentication

OSLC Services MAY protected resources with OAuth Authentication.

Form Based Authentication

OSLC Services MAY use other authentication mechanisms, including those common described as Form Based Authentication. OSLC Services that choose to use other authentication mechanisms are responsible for specifying how those mechanisms work.

Error Status Information

Whenever an HTTP request results in an error, a status code in the range of 400-599 is returned from the server. A service provider returns a response body containing additional information about the error. The response's body media type MUST be application/rdf+xml, with the following properties defined in the http://open-services.net/xmlns/common/1.0 namespace:

• oslc:statusCode - required element containing HTTP status code corresponding to this request (this is a replication of the code in the response status line).
• oslc:message - required element containing an error message string suitable for presentation to a user of the client
• oslc:url - optional element whose string content is a URL indicating a Web presentation giving more information on the error
  • oslc:rel - optional attribute with value of "alternate" indicating that it is an alternate method to resolve the error
  • oslc:hintWidth - optional attribute
  • oslc:hintHeight - optional attribute

Implementations MAY provide additional properties. The error message text SHOULD be appropriate to the locale of the requesting client.

Examples

In application/rdf+xml format:

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:oslc="http://open-services.net/ns/core#">

    <oslc:Error>
        <oslc:statusCode>409</oslc:statusCode>
        <oslc:message>The request to change the resource does not have the most recent ETag value.</oslc:message>
    </oslc:Error>

</rdf:RDF>

Another example including a reference to an HTML page with additional information and possible alternate solution to the error.

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF 
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"     
  xmlns:oslc="http://open-services.net/ns/core#">

    <oslc:Error>
        <oslc:statusCode>409</oslc:statusCode>
        <oslc:message>Invalid ETag value.</oslc:message>
        <oslc:extendedError>
           <oslc:ExtendedError oslc:rel="alternate" oslc:hintWidth="200px" oslc:hintHeight="200px">
              <oslc:moreInfo rdf:resource="https://am.acme.com/messages?ref=a329df3aeef5543"/>
           </oslc:ExtendedError>
        </oslc:extendedError>     
    </oslc:Error> 

</rdf:RDF>

References

• RFC2616 HTTP