Collection.next+JSON - Document Format

Description

Collection.next+JSON is a JSON-based read/write hypermedia-type designed to support management and querying of nested data collections. Collection.next+JSON is an extension of Collection+JSON hypermedia format.

Contents

NOTE:The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in
RFC2119.

NOTE:The data type names "OBJECT", "ARRAY", "NUMBER", "STRING", and "VALUE" in this document are to be interpreted as described in
Collection+JSON specification.

1. General Concepts and Goals

Section defines general concepts describing all extensions to
Collection+JSON specification.

Main goal of this extension is to improve existing capabilities of
Collection+JSON
further and add more power and expressiveness to existing features of specification.

Extension introduces several new
objects,
arrays and
properties and adds more flexibility and semantics to various areas of base specification.

When Collection.next+JSON document format is used for implementing APIs application/vnd.collection.next+json MUST be used as a value of the
Accept and
Content-Type headers as shown in the examples below:

Support of HTTP's GET and HEAD methods SHOULD be always assumed by clients.

2.4. enctype

The enctype object represents a list of all supported content types other than
application/vnd.collection.next+json which potentially MAY be accepted by server for write requests.
This is an OPTIONAL object and is a child property of of the
template object.

4.1. type

4.1.1. Using type property with links array elements

When used with
the links
array elements the value SHOULD be a standard MIME type. If the
type property does not appear on a
links
array element, it should be assumed to be set to application/vnd.collection.next+json.

By reducing need to describe types of the input objects somewhere else, minimize hardcoding in service clients.

Improve rendering options in client applications. Client applications MAY determine rendering strategy by relying on
the value of the type
property and use most appropriate input controls in order to increase quality of interaction between application and user.

Table below describes supported HTML5 input types which service implementors and clients MAY user in order to describe and determine meaning of the input objects:

As far as the form relation value is intentionally generic service implementors MAY support various types of forms.
Different types of forms SHOULD be indicated by the type property value in links array elements.