Common Service Elements



Download 1.14 Mb.
Page1/4
Date26.04.2018
Size1.14 Mb.
#46906
  1   2   3   4
  1. Binding

    1. Overview


The CMIS Browser Binding is designed to allow developers build browser based applications that use CMIS content. It is based on technologies that developers who build such applications already understand, including HTML, HTML Forms, JavaScript and JSON. Importantly, it does not require a JavaScript library, but rather takes advantage of capabilities already built into modern browsers.

While this binding is optimized for use in browser applications; it can also be useful as a simpler HTTP based binding in other application models.


    1. Common Service Elements

      1. Protocol


HTTP SHALL be used as the protocol for service requests. HTTP GET SHALL be used for reading content and HTTP POST SHALL be used for creating, updating and deleting content. Using just those two HTTP verbs makes it possible to develop applications that rely on built-in browser capabilities (e.g. HTML Forms) and typical server configurations.
      1. Data Representation


Browser applications are typically written in JavaScript. A popular lightweight data representation format amongst JavaScript developers is JavaScript Object Notation (JSON) as described in RFC 4627 (see http://www.ietf.org/rfc/rfc4627.txt). JSON SHALL be used to represent the various CMIS objects described by the data model.
        1. Schema


It is useful to formally define CMIS elements as they appear in JSON using a schema language. This makes the definition more precise and concise, and also allows implementations to validate CMIS JSON instances at run-time.

Since there is not yet a JSON schema language approved by a standards body, this specification uses a schema language called Orderly that is introduced by Lloyd Hilaiel on http://orderly-json.org/. Since the definition of Orderly on http://orderly-json.org/ may proceed independently of this specification, and because we may need to extend Orderly to define some elements of CMIS, we provide a description of Orderly in Appendix B of this document.


        1. Mapping Schema Elements to JSON


JSON only defines a few types, including Object, String, Number, Boolean, Null and Arrays. Since not all the types used in the CMIS schema have direct JSON equivalents, some explanation of mapping is necessary.

CMIS

JSON

String

string

boolean

boolean

Decimal

number

Integer

number

Datetime

number (milliseconds since 1970/01/01, UTC)

Uri

string

Id

string

Html

string
      1. URL Patterns


The URL’s used by the Browser Binding are meant to be predictable in order to simplify client development. The URL patterns allow objects to be referenced both by object ID and by path. Section 1.3 provides the details of how clients can construct these URL’s.
      1. Multipart Forms


Browser applications also typically use HTTP multipart forms as described in RFC 2388 (see http://tools.ietf.org/html/rfc2388) to create and update content. This is especially useful for updating file content with the addition of the FILE attribute in RFC 1867 (see http://tools.ietf.org/html/rfc1867). In this binding, HTTP POST of multipart/form-data SHALL be used to update content streams.
      1. Properties in a “value not set” state


The JSON value “null” SHALL be used by the server when returning values that have not been set.
      1. Client Token


The JSONP (JSON with Padding) pattern allows a client to fetch JSON content from a server, wrapped in a client provided token. For example, this pattern allows JSON content fetched by using the src attribute in JavaScript to be passed directly to a JavaScript function in an HTML page. This allows the handling of content from multiple servers which otherwise would be rejected by the browser following the “same origin policy”.

This binding introduces a parameter called clientToken to allow CMIS clients to use this pattern.

The clientToken MAY be included by clients on read operations defined by this protocol that answer a JSON object. The server SHALL respond to valid read requests containing this token by answering the token, followed by an open parenthesis, followed by the JSON object returned, followed by a close parenthesis. If the parameter is included in a request, the server SHALL validate that its value is not empty but the server SHALL NOT do any additional validation of the token, such as, for example, assuring it conforms to JavaScript function naming conventions. If the parameter value is empty, or if the parameter is used on a service for which it is not allowed, then the invalidArgument exception SHALL be used to signal the error.

      1. Authentication


Authentication SHOULD be handled by the transport protocol. Please see AtomPub (RFC5023) section 14.
      1. Error Handling and Return Codes


HTTP Return Codes SHALL be used to indicate success or failure of an operation. Please see the HTTP specification for more information on the HTTP status codes. These are provided as guidance from the HTTP specification. If any conflict arises, the HTTP specification is authoritative.

CMIS Services Exception HTTP Status Code

invalidArgument 400

objectNotFound 404

permissionDenied 403

notSupported 405

runtime 500

constraint 409

filterNotValid 400

streamNotSupported 403

storage 500

contentAlreadyExists 409

versioning 409

updateConflict 409

nameConstraintViolation 409

This binding also introduces an object to return additional information about the response. CMIS repositories SHOULD include this object in responses. When present, the object SHALL include the following JSON properties.



string exception

A string containing one of the CMIS services exceptions describe in section 1.2.8



string message

A string containing a message that provides more information about what caused the exception.

Example:

GET /cmis/repository/123/myFolder?foo=bar&maxItems=20 HTTP/1.1

Host: www.example.com

User-Agent: Mozilla/5.0


HTTP/1.1 400 OK

Content-Type: application/json

Content-Length: xxxx
{

"exception": "invalidArgument",

"message": "The parameter ‘foo’ is not valid."

}


    1. Directory: committees -> download.php
      download.php -> Emergency Interoperability Consortium Membership Meeting
      download.php -> Technical Communicators, Get ready: Here comes Augmented Reality! Rhonda Truitt
      download.php -> Oasis set tc
      download.php -> Iepd analyze Requirements Use Cases for edxl situation reporting messages Draft Version 4
      download.php -> Technical Committee: oasis transformational Government Framework tc chair
      download.php -> Ibops protocol Version 0 Working Draft 2 9 March 2015 Technical Committee
      download.php -> Reliability of Messages Sent as Responses over an Underlying Request-response Protocol
      download.php -> Service Component Architecture sca-j common Annotations and apis Specification Version 1 Committee Draft 03 – Rev1 + Issue 127
      download.php -> Scenario Two – Hurricane Warning
      download.php -> Technical Committee: oasis augmented Reality in Information Products (arip) tc chairs

      Download 1.14 Mb.

      Share with your friends:
  1   2   3   4




The database is protected by copyright ©ininet.org 2024
send message

    Main page