REST Interface Overview

This document describes how the Member (Member Node APIs) and Coordinating (Coordinating Node APIs) Node APIs are implemented using a Representational State Transfer (REST) approach over HTTP.

Key points on REST interactions in DataONE:

1. Content is generally modeled as collections, with PIDs identifying individual items of a collection.
2. The HTTP verbs HEAD, GET, POST, PUT, DELETE are used for retrieving information about content, retrieving content, creating content, updating content, and deleting content respectively.
3. State information, if required, is passed in the HTTP headers.
4. Identity transfer is performed using SSL, with the client certificate accessible through implementation specific mechanisms supported by the respective server environment.
5. The identity information described in (4) is indicated as a Session in the method signatures and their descriptions.
6. Hints to support efficient caching (e.g. content time stamps) should be respected. Caching is an important mechanism for assisting with service scalability.
7. Names of parameters passed in URLs or message bodies are case sensitive unless explicitly indicated otherwise. If the case of the parameters names does not match the method signature, the request MAY be rejected with an Exceptions.InvalidRequest exception.
8. GET, HEAD, DELETE requests only pass parameters as part of the URL. The parameter values are converted to UTF-8 Strings and appropriately escaped for incorporating into the URL.
9. Message bodies (e.g. for POST and PUT requests) are encoded using MIME Multipart, mixed (RFC2046).
10. PUT requests are for updating an existing resource. An identifier of some sort will typically appear in the URL (e.g. a PID or a Subject), which should be a UTF-8 string and appropriately URL path encoded. The message body will be MIME multipart/mixed and may contain values expressed as parameter and / or file parts as described in (12) below.
11. POST requests are for creating resources. All information for creating the new object or resource is transmitted in the message body, which is encoded as a MIME multipart/mixed message.
12. We use two types of content in MIME multipart/mixed messages: parameters and files. Parameters are to be used for all simple types (13, below). Files are to be used for all complex types (14, below) and for octet streams.
13. Simple types are structures that contain a single value. When creating the parameter entry, the value is converted to a UTF-8 String using formatting equivalent to what is used when expressing the same value as part of an XML document (e.g. when serializing using PyxB or JibX). The expression of a simple type as a String in a MIME multipart/mixed parameter should be equivalent to expressing the same value as part of a URL (before escaping).
14. Complex types are any structures that contain more than a single value. A simple example of a complex type is the Types.Checksum type. It is a String (the checksum) with an attribute (the algorithm). Complex types are serialized to UTF-8 encoded XML structures that are defined by the DataONE Types Schema.
15. File parts of MIME multipart/mixed have three properties: the name of the entry, the file name of the content, and the content. The name of the entry must match the parameter name as described in the signature of the method being called. The content of the entry is XML encoded structure as described in (14) above (or an octet stream). The file name property is not used, and can be set to whatever the client considers appropriate. The file name MAY be ignored by the service receiving the request.

Collections exposed by Member Nodes and Coordinating Nodes include:

/object:The set of objects available for retrieval from the node. /meta:Metadata about objects available for retrieval from the node. /formats:Object formats registered on the node. /log:Log records held on the node. /reserve:Identifiers that have been reserved for future use. /accounts:Principal and ownership related functionality. /sessions:Authenticated session management functions. /node:Service and status information for all nodes on the system. /monitor:Node health monitoring /replicate:Member node to member node replication functionality

Message Serialization

The format of the response (except for responses from MNRead.get() or CNRead.get()) is determined by the Accept: header provided in the request.

Version 1.0 of the DataONE services only support XML serialization, and this format MUST be supported by all services and clients interacting with the DataONE system.

All request and response documents MUST be encoded using the UTF-8 character set.

If the service is not able to provide a response in the specified format, then the node should return an error code of Exceptions.NotImplemented, with the HTTP error code set to 406.

Parameters in Requests

Many of the URL patterns described here accept parameters in the URL and as components of a MIME multipart-mixed message body.

Unless otherwise indicated, all parameter names and values should be considered case sensitive.

Session Information

Session information (formerly referred to as a token) is obtained from the client side authentication certificate held by the SSL processing library of the HTTPS service handling the request. Hence, even though a session parameter may be present in the method signature, the session information itself is transported as part of the HTTPS handshaking process and is not present in the body or header section of the HTTP request.

URL Path Parameters

Some parameters are passed as part of the REST service URL path (e.g. /get/{pid}). Such values MUST be encoded according to the rules of RFC3986 with the additional restriction that the space character MUST be encoded as “%20” rather than “+”. Examples of DataONE REST URLs for retrieving an object (i.e. the get() operation):

PID: 10.1000/182
URL: https://mn.example.com/mn/v1/object/10.1000%2F182

PID: http://example.com/data/mydata?row=24
URL: https://mn.example.com/mn/v1/object/http:%2F%2Fexample.com%2Fdata%2Fmydata%3Frow=24

PID: Is_féidir_liom_ithe_gloine
URL: https://mn.example.com/mn/v1/object/Is_f%C3%A9idir_liom_ithe_gloine

URL Query Parameters

Parameters passed as key, values parameters in the URL query string MUST be appropriately encoded for transmission as part of the URL according to RFC3986 rules for the URL query component. In addition, the space character MUST be encoded as “%20” rather than the alternative “+” character.

Boolean URL Query Parameters

Where a boolean parameter value is being specified as the value portion of a key-value pair appearing in a URL, the strings “true” and “false” MUST be used to indicate logical true and logical false respectively.

Date Parameters in URLs

Date values in URLs should be formatted as:

yyyy-MM-dd[Thh:mm:ss.S[+ZZ:zz]]

Where:

yyyy = Four digit year
MM   = Two digit month, 01 = January
dd   = Two digit day of month, 01 = first day
hh   = Hour of day, 00 - 23
mm   = Minute of hour, 00 - 59
ss   = Second of minute, 00 - 59
S    = Milliseconds
ZZ   = Hours of timezone offset
zz   = Minutes of timezone offset

If the timezone values are not present then the date time is interpreted to be in GMT.

If the time portion of the date time is not present, then the time is assumed to be 00:00:00.0, i.e. the first millisecond of the specified date.

Message Body in PUT or POST

Requests sent using the HTTP POST or PUT verbs MUST use MIME multipart-mixed encoding of the message body as described in RFC2046. In most cases and unless otherwise indicated, all parameters for PUT and POST requests except the authorization session will be sent in the message body (as opposed to URL parameters).

Example of a HTTP POST request to the MN create() method using curl:

curl -X POST \
     --cert /tmp/x509up_u502 \
     -H "Charset: utf-8" \
     -H "Content-Type: multipart/mixed; boundary=----------6B3C785C-6290-11DF-A355-A6ECDED72085_$" \
     -H "Accept: text/xml" \
     -H "User-Agent: pyd1/1.0 +http://dataone.org/" \
     -F pid=10Dappend1.txt \
     -F object=@content.bin \
     -F sysmeta=@systemmetadata.abc \
     "https://demo1.test.dataone.org/knb/d1/mn/v1/object"

Example serialized body of a HTTP POST request to the MN create() method (excluding session information):

TODO

Message Body in DELETE

RFC2046 does not explicitly prevent the presence of a message body in a HTTP DELETE request, however support for transmission of the request payload may vary by technology. DELETE requests requiring a request payload MUST have accompanying integration tests that exercise the technologies involved.

REST Endpoint Summary

REST URLs implemented on Member Nodes.

Path	Method	Description
GET /monitor/ping	MNCore.ping()	Low level “are you alive” operation. A valid ping response is indicated by a HTTP status of 200. A timestmap indicating the current system time (UTC) on the node MUST be returned in the HTTP Date header. The Member Node should perform some minimal internal functionality testing before answering. However, ping checks will be frequent (every few minutes) so the internal functionality test should not be high impact. Any status response other than 200 indicates that the node is offline for DataONE operations. Note that the timestamp returned in the Date header should follow the semantics as described in the HTTP specifications, http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.18 The response body will be ignored by the caller except in the case of an error, in which case the response body should contain the appropriate DataONE exception.
GET /log?[fromDate={fromDate}][&toDate={toDate}][&event={event}][&pidFilter={pidFilter}][&start={start}][&count={count}]	MNCore.getLogRecords()	Retrieve log information from the Member Node for the specified slice parameters. This method is used primarily by the log aggregator to generate aggregate statistics for nodes, objects, and the methods of access. The response MUST contain only records for which the requestor has permission to read. Note that date time precision is limited to one millisecond. If no timezone information is provided UTC will be assumed. Access control for this method MUST be configured to allow calling by Coordinating Nodes and MAY be configured to allow more general access.
GET / and GET /node	MNCore.getCapabilities()	Returns a document describing the capabilities of the Member Node. The response at the Member Node base URL is for convenience only. Clients of Member Nodes SHOULD use the /node URL to retrieve the node capabilities document.
GET /object/{pid}	MNRead.get()	Retrieve an object identified by pid from the node. The response MUST contain the bytes of the indicated object, and the checksum of the bytes retrieved SHOULD match the SystemMetadata.checksum recorded in the Types.SystemMetadata. If the object does not exist on the node servicing the request, then Exceptions.NotFound must be raised even if the object exists on another node in the DataONE system. Also implmented by Coordinating Nodes as CNRead.get().
GET /meta/{pid}	MNRead.getSystemMetadata()	Describes the object identified by pid by returning the associated system metadata object. If the object does not exist on the node servicing the request, then Exceptions.NotFound MUST be raised even if the object exists on another node in the DataONE system.
HEAD /object/{pid}	MNRead.describe()	This method provides a lighter weight mechanism than MNRead.getSystemMetadata() for a client to determine basic properties of the referenced object. The response should indicate properties that are typically returned in a HTTP HEAD request: the date late modified, the size of the object, the type of the object (the SystemMetadata.formatId). The principal indicated by token must have read privileges on the object, otherwise Exceptions.NotAuthorized is raised. If the object does not exist on the node servicing the request, then Exceptions.NotFound must be raised even if the object exists on another node in the DataONE system. Note that this method is likely to be called frequently and so efficiency should be taken into consideration during implementation.
GET /checksum/{pid}[?checksumAlgorithm={checksumAlgorithm}]	MNRead.getChecksum()	Returns a Types.Checksum for the specified object using an accepted hashing algorithm. The result is used to determine if two instances referenced by a PID are identical, hence it is necessary that MNs can ensure that the returned checksum is valid for the referenced object either by computing it on the fly or by using a cached value that is certain to be correct.
GET /object[?fromDate={fromDate}&toDate={toDate} &formatId={formatId}&replicaStatus={replicaStatus} &start={start}&count={count}]	MNRead.listObjects()	Retrieve the list of objects present on the MN that match the calling parameters. This method is required to support the process of Member Node synchronization. At a minimum, this method MUST be able to return a list of objects that match:: fromDate < SystemMetadata.dateSysMetadataModified but is expected to also support date range (by also specifying toDate), and should also support slicing of the matching set of records by indicating the starting index of the response (where 0 is the index of the first item) and the count of elements to be returned. Note that date time precision is limited to one millisecond. If no timezone information is provided, the UTC will be assumed. Access control for this method MUST be configured to allow calling by Coordinating Nodes and MAY be configured to allow more general access.
POST /error	MNRead.synchronizationFailed()	This is a callback method used by a CN to indicate to a MN that it cannot complete synchronization of the science metadata identified by pid. When called, the MN should take steps to record the problem description and notify an administrator or the data owner of the issue. A successful response is indicated by a HTTP status of 200. An unsuccessful call is indicated by a returned exception and associated HTTP status code. Access control for this method MUST be configured to allow calling by Coordinating Nodes and MAY be configured to allow more general access.
GET /replica/{pid}	MNRead.getReplica()	Called by a target Member Node to fullfill the replication request originated by a Coordinating Node calling MNReplication.replicate(). This is a request to make a replica copy of the object, and differs from a call to GET /object in that it should be logged as a replication event rather than a read event on that object. If the object being retrieved is restricted access, then a Tier 2 or higher Member Node MUST make a call to CNReplication.isNodeAuthorized() to verify that the Subject of the caller is authorized to retrieve the content. A successful operation is indicated by a HTTP status of 200 on the response. Failure of the operation MUST be indicated by returning an appropriate exception.
GET /isAuthorized/{pid}?action={action}	MNAuthorization.isAuthorized()	Test if the user identified by the provided session has authorization for operation on the specified object. A successful operation is indicated by a return HTTP status of 200. Failure is indicated by an exception such as NotAuthorized being returned. The body of the response is arbitrary and SHOULD be ignored by the caller. If the action is not authorized, then a NotAuthorized exception MUST be raised. .. Note:: Should perhaps add convenience methods for “canRead()” and “canWrite()” to verify that a user is able to read / write an object.
POST /dirtySystemMetadata	MNAuthorization.systemMetadataChanged()	Notifies the Member Node that the authoritative copy of system metadata on the Coordinating Nodes has changed. The Member Node SHOULD schedule an update to its information about the affected object by retrieving an authoritative copy from a Coordinating Node. Note that date time precision is limited to one millisecond. Access control for this method MUST be configured to allow calling by Coordinating Nodes.
POST /object	MNStorage.create()	Called by a client to adds a new object to the Member Node. The pid must not exist in the DataONE system or should have been previously reserved using CNCore.reserveIdentifier(). The caller MUST have authorization to write or create content on the Member Node.
PUT /object/{pid}	MNStorage.update()	This method is called by clients to update objects on Member Nodes. Updates an existing object by creating a new object identified by newPid on the Member Node which explicitly obsoletes the object identified by pid through appropriate changes to the SystemMetadata of pid and newPid. The Member Node sets SystemMetadata.obsoletedBy on the object being obsoleted to the pid of the new object. It then updates SystemMetadata.dateSysMetadataModified on both the new and old objects. The modified system metadata entries then become available in MNRead.listObjects(). This ensures that a Coordinating Node will pick up the changes when filtering on SystmeMetadata.dateSysMetadataModified.
POST /generate	MNStorage.generateIdentifier()	Given a scheme and optional fragment, generates an identifier with that scheme and fragment that is unique. The message body is encoded as MIME Multipart/form-data
DELETE /object/{pid}	MNStorage.delete()	Deletes an object managed by DataONE from the Member Node. Member Nodes MUST check that the caller (typically a Coordinating Node) is authorized to perform this function. The delete operation will be used primarily by Coordinating Nodes to help manage the number of replicas of an object that are present in the entire system. The operation removes the object from further interaction with DataONE services. The implementation may delete the object bytes, and in general should do so since a delete operation may be in response to a problem with the object (e.g. it contains malicious content, is innappropriate, or is the subject of a legal request). If the object does not exist on the node servicing the request, then an Exceptions.NotFound exception is raised. The message body of the exception SHOULD contain a hint as to the location of the CNRead.resolve() method.
PUT /archive/{pid}	MNStorage.archive()	Hides an object managed by DataONE from search operations, effectively preventing its discovery during normal operations. The operation does not delete the object bytes, but instead sets the Types.SystemMetadata.archived flag to True. This ensures that the object can still be resolved (and hence remain valid for existing citations and cross references), though will not appear in searches. Member Nodes MUST check that the caller is authorized to perform this function. If the object does not exist on the node servicing the request, then an Exceptions.NotFound exception is raised. The message body of the exception SHOULD contain a hint as to the location of the CNRead.resolve() method.
POST /replicate	MNReplication.replicate()	Called by a Coordinating Node to request that the Member Node create a copy of the specified object by retrieving it from another Member Nodeode and storing it locally so that it can be made accessible to the DataONE system. A successful operation is indicated by a HTTP status of 200 on the response. Failure of the operation MUST be indicated by returning an appropriate exception. Access control for this method MUST be configured to allow calling by Coordinating Nodes.
GET /query/{queryEngine}/{query}	MNQuery.query()	Submit a query against the specified queryEngine and return the response as formatted by the queryEngine. The query() operation may be implemented by more than one type of search engine and the queryEngine parameter indicates which search engine is targeted. The value and form of query is determined by the specific query engine. For example, the SOLR search engine will accept many of the standard parameters of SOLR, including field restrictions and faceting. This method is optional for Member Nodes, but if implemented, both getQueryEngineDescription and listQueryEngines must also be implemented. .. NOTE:: This method is in DRAFT status and is scheduled for version 1.1 of the APIs
GET /query/{queryType}	MNQuery.getQueryEngineDescription()	Provides metadata about the query service of the specified queryEngine. The metadata provides a brief description of the query engine, its version, its schema version, and an optional list of fields supported by the query engine. .. NOTE:: This method is in DRAFT status and is scheduled for version 1.1 of the APIs
GET /query	MNQuery.listQueryEngines()	Returns a list of query engines, i.e. supported values for the queryEngine parameter of the getQueryEngineDescription and query operations. The list of search engines available may be influenced by the authentication status of the request. .. NOTE:: This method is in DRAFT status and is scheduled for version 1.1 of the APIs

REST URLs implemented on Coordinating Nodes.

Path	Method	Description
GET /monitor/ping	CNCore.ping()	Low level “are you alive” operation. A valid ping response is indicated by a HTTP status of 200. A timestmap indicating the current system time (UTC) on the node MUST be returned in the HTTP Date header. The Member Node should perform some minimal internal functionality testing before answering. However, ping checks will be frequent (every few minutes) so the internal functionality test should not be high impact. Any status response other than 200 indicates that the node is offline for DataONE operations. Note that the timestamp returned in the Date header should follow the semantics as described in the HTTP specifications, http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.18 The response body will be ignored by the caller expect in the case of an error, in which case the response body should contain the appropriate DataONE exception.
POST /object	CNCore.create()	Used internally within a Coordinating Node to add a new object to the object store. This method is not publicly exposed by a Coordinating Node.
GET /formats	CNCore.listFormats()	Returns a list of all object formats registered in the DataONE Object Format Vocabulary.
GET /formats/{formatId}	CNCore.getFormat()	Returns the object format registered in the DataONE Object Format Vocabulary for the given format identifier.
GET /log?[fromDate={fromDate}][&toDate={toDate}][&event={event}][&pidFilter={pidFilter}][&start={start}][&count={count}]	CNCore.getLogRecords()	Retrieves consolidated log information for the specified date range (fromDate < timestamp <= toDate) for the entire DataONE infrastructure Note that date time precision is limited to one millisecond. If no timezone information is provided, the UTC will be assumed. Note that full access to log records requires access through a priviledged account. A public user may be presented with an empty response.
POST /reserve	CNCore.reserveIdentifier()	Reserves the identifier that is unique and can not be used by any other sessions. Future calls to MNStorage.create() and MNStorage.update() that reference this ID must be made by the same principal making the reservation, otherwise an error is raised on those methods. The requested identifier is transmitted in a MIME Multipart/form-data body with pid as key, and the identifier string as value.
POST /generate	CNCore.generateIdentifier()	Given a scheme and optional fragment, generates an identifier with that scheme and fragment that is unique. The message body is encoded as MIME Multipart/form-data
GET /checksum	CNCore.listChecksumAlgorithms()	Returns a list of checksum algorithms that are supported by DataONE.
PUT /obsoletedBy/{pid}	CNCore.setObsoletedBy()	Updates the Types.SystemMetadata.obsoletedBy property for an object, indicating that the object specified by pid has been obsoleted by the identifier in obsoletedByPid.
DELETE /object/{pid}	CNCore.delete()	Deletes an object from the entire DataONE system, including all nodes known to hold a copy of the object. The PID of the object will continue to be shown as in use (preventing its reuse for other objects), however the object should not be resolvable (NotFound) or retrievable. The delete operation is used only by administrators in response to a request to remove an object from DataONE, perhaps because of legal requirements or the object has been identified as containing malicious content.
PUT /archive/{pid}	CNCore.archive()	Hides an object managed by DataONE from search operations, effectively preventing its discovery during normal operations. The operation does not delete the object bytes, but instead sets the Types.SystemMetadata.archived flag to True. This ensures that the object can still be resolved (and hence remain valid for existing citations and cross references), though will not appear in searches. The CN should ensure that all MNs holding a copy of the object are informed of the change so that they may update their information about the object.
GET /node	CNCore.listNodes()	Returns a list of nodes that have been registered with the DataONE infrastructure.
POST /meta	CNCore.registerSystemMetadata()	Provides a mechanism for adding system metadata independently of its associated object, such as when adding system metadata for data objects. This method is used internally by Coordinating Nodes.
GET /reserve/{pid}?subject={subject}	CNCore.hasReservation()	Checks to determine if the supplied subject is the owner of the reservation of pid. A positive response (that the pid is reserved and owned by subject) is indicated by a return of a HTTP status of 200. A negative response is indicated by an exception and the associated HTTP status code.
GET /object/{pid}	CNRead.get()	Retrieves the object identified by pid from the node. If the object is not present on the node, then an Exceptions.NotFound error is raised, regardless of whether the object exists on another node in the DataONE system.
GET /meta/{pid}	CNRead.getSystemMetadata()	Returns the system metadata that contains DataONE specific information about the object identified by pid. Authoritative copies of system metadata are only available from the Coordinating Nodes.
HEAD /object/{pid}	CNRead.describe()	This method provides a lighter weight mechanism than CNRead.getSystemMetadata() for a client to determine basic properties of the referenced object. The response should indicate properties that are typically returned in a HTTP HEAD request: the date late modified, the size of the object, the type of the object (the SystemMetadata.formatId). The principal indicated by token must have read privileges on the object, otherwise Exceptions.NotAuthorized is raised. If the object does not exist on the node servicing the request, then Exceptions.NotFound must be raised even if the object exists on another node in the DataONE system. Note that this method is likely to be called frequently and so efficiency should be taken into consideration during implementation.
GET /resolve/{pid}	CNRead.resolve()	Returns a list of nodes (MNs or CNs) known to hold copies of the object identified by pid. The object resolution process is intended to provide a simple mechanism for a client to discover from which node(s) a particular object may be retrieved. Details about method interfaces (i.e. REST URLs) exposed by a particular node can be determined by examining the response from the node collection. For convenience, the MNRead.get() URL is included in the response as is the base URL of the node REST services. Note also that the same functionality as resolve() can be implemented by retrieving a copy of the system metadata for the object and utilizing the node registry to discover the base URL from which the client can construct the get() URL. Resolve is provided for efficiency since the response size is much smaller. Resolve will return a HTTP status of 303 (see other) on success. The HTTP header “Location” MUST be set, and it’s value SHOULD be the full get() URL for retrieving the object from the first location in the resolve response.
GET /checksum/{pid}	CNRead.getChecksum()	Returns the checksum for the specified object as reported in the system metadata. Note that the signature of this method differs from MNRead.getChecksum() as that method takes an optional algorithm parameter.
GET /object[?fromDate={fromDate}&toDate={toDate}&formatId= {formatId}&replicaStatus={replicaStatus}&start={start}&count={count}]	CNRead.listObjects()	Retrieve the list of objects present on the CN that match the calling parameters. At a minimum, this method should be able to return a list of objects that match:: fromDate < SystemMetadata.dateSysMetadataModified but is expected to also support date range (by also specifying toDate), and should also support slicing of the matching set of records by indicating the starting index of the response (where 0 is the index of the first item) and the count of elements to be returned. Note that date time precision is limited to one millisecond. If no timezone information is provided, the UTC will be assumed.
GET /search/{queryType}/{query}	CNRead.search()	Search the metadata catalog and return identifiers of metadata records that match the criteria. Search may be implemented by more than one type of search engine. The queryType parameter indicates which search engine should be targeted. The value and form of query is determined by the search engine. Currently supported search engines include: “solr”
GET /query/{queryEngine}/{query}	CNRead.query()	Submit a query against the specified queryEngine and return the response as formatted by the queryEngine. The query() operation may be implemented by more than one type of search engine and the queryEngine parameter indicates which search engine is targeted. The value and form of query is determined by the specific query engine. For example, the SOLR search engine will accept many of the standard parameters of SOLR, including field restrictions and faceting. .. NOTE:: This method is in DRAFT status and is scheduled for version 1.1 of the APIs
GET /query/{queryType}	CNRead.getQueryEngineDescription()	Provides metadata about the query service of the specified queryEngine. The metadata provides a brief description of the query engine, its version, its schema version, and an optional list of fields supported by the query engine. .. NOTE:: This method is in DRAFT status and is scheduled for version 1.1 of the APIs
GET /query	CNRead.listQueryEngines()	Returns a list of query engines, i.e. supported values for the queryEngine parameter of the getQueryEngineDescription and query operations. The list of search engines available may be influenced by the authentication status of the request. .. NOTE:: This method is in DRAFT status and is scheduled for version 1.1 of the APIs
PUT /owner/{pid}	CNAuthorization.setRightsHolder()	Changes ownership (RightsHolder) of the specified object to the subject specified by userId
GET /isAuthorized/{pid}?action={action}	CNAuthorization.isAuthorized()	Test if the user identified by the provided token has authorization for operation on the specified object. A successful operation is indicated by a return HTTP status of 200. Failure is indicated by an exception such as NotAuthorized being returned. A successful response is indicated by a response HTTP status of 200. The body of the response is arbitrary and SHOULD be ignored by the caller. If the action is not authorized, then a NotAuthorized exception MUST be raised. .. Note:: Should perhaps add convenience methods for “canRead()” and “canWrite()” to verify that a user is able to read / write an object.
PUT /accessRules/{pid}	CNAuthorization.setAccessPolicy()	Sets the access permissions for an object identified by pid. Triggers a change to the system metadata modified time stamp. Successful completion of this operation is indicated by a HTTP response status code of 200. Unsuccessful completion of this operation MUST be indicated by returning an appropriate exception such as NotAuthorized.
POST /accounts	CNIdentity.registerAccount()	Create a new subject in the DataONE system. Note that there should probably be a lot more metadata captured about the new user, and there should be a mechanism for specifying the default access control rules for the new account.
PUT /accounts/{subject}	CNIdentity.updateAccount()	Update an existing subject in the DataONE system. The target subject is determined from subject provided in the URL. The use calling this method must have write access to the account details. Note that there should be a policy for verifying the details that change via this method.
PUT /accounts/verification/{subject}	CNIdentity.verifyAccount()	Verify that the Person data associated with this Subject is a true representation of the real world person. This service can only be called by users who have an administrative role for the domain of users in question. A successful completion of this operation is indicated by returning a HTTP status of 200. An exeption MUST be returned if the account verification is not successful.
GET /accounts/{subject}	CNIdentity.getSubjectInfo()	Get the information about a Person (their equivalent identities, and the Groups to which they belong) or the Group (including members).
GET /accounts?query={query}[&status={status}&start={start}&count={count}]	CNIdentity.listSubjects()	List the subjects, including users, groups, and systems, that match search criteria. The list can be restricted to subjects whose identifier matches certain substrings, and the size of the resultset can be paged through.
POST /accounts/map	CNIdentity.mapIdentity()	Create a new mapping between the two identities, asserting that they represent the same subject. Mapping identities with this method requires explicit authorization for the user given in the Session object. The caller must have made sure that the primary and secondary identities represent one and the same individual. Successful completion of the request is indicated by returning a HTTP status of 200. A failed request MUST be indicated by returning an appropriate exception and setting the response HTTP status accordingly.
DELETE /accounts/map/{subject}	CNIdentity.removeMapIdentity()	Removes a previously asserted identity mapping from the Subject in the Session to the Subject given by the parameter. The reciprocol mapping entry is also removed. A successful request is indicated by returning a HTTP status of 200. A failed request MUST be indicated by returning an appropriate exception and setting the response HTTP status accordingly.
POST /accounts/pendingmap	CNIdentity.requestMapIdentity()	Request a new mapping between the authenticated identity in the session and the given identity, asserting that they represent the same subject. Mapping identities is a two-step process wherein a map request is made by a primary Subject and a subsequent (confirmation) map request is made by the secondary Subject. This ensures that mappings are performed only by those that have authority to do so. Successful completion of the request is indicated by returning a HTTP status of 200. A failed request MUST be indicated by returning an appropriate exception and setting the response HTTP status accordingly.
PUT /accounts/pendingmap/{subject}	CNIdentity.confirmMapIdentity()	Confirms a previously initiated identity mapping. If subject A asserts that B is the same identity through CNIdentity.requestMapIdentity(), then this method is called by B to confirm that assertion. A successful request is indicated by returning a HTTP status of 200. A failed request MUST be indicated by returning an appropriate exception and setting the response HTTP status accordingly.
GET /accounts/pendingmap/{subject}	CNIdentity.getPendingMapIdentity()	Gets the SubjectInfo of a previously initiated identity mapping. A successful request is indicated by returning a HTTP status of 200. A failed request MUST be indicated by returning an appropriate exception and setting the response HTTP status accordingly.
DELETE /accounts/pendingmap/{subject}	CNIdentity.denyMapIdentity()	Denies a previously initiated identity mapping. If subject A asserts that B is the same identity through CNIdentity.requestMapIdentity(), then this method is called by B to deny that assertion. A successful request is indicated by returning a HTTP status of 200. A failed request MUST be indicated by returning an appropriate exception and setting the response HTTP status accordingly.
POST /groups	CNIdentity.createGroup()	Create a group with the given name. Groups are lists of subjects that allow all members of the group to be referenced by listing solely the subject name of the group. Group names must be unique within the DataONE system. Groups can only be modified by Subjects listed as rightsHolders.
PUT /groups	CNIdentity.updateGroup()	Add members to the named group. Group members can be modified only by the original creator of the group, otherwise a NotAuthorized exception is thrown. Group members are provided as a list of subjects that replace the group membership. Successful completion of this operation is indicated by a HTTP response status code of 200. Unsuccessful completion of this operation MUST be indicated by returning an appropriate exception.
PUT /replicaNotifications/{pid}	CNReplication.setReplicationStatus()	Update the replication status of the system metadata, ensuring that the change is appropriate for the given state of system metadata. For example, a MN can not change the status to COMPLETED unless the CN previously requested replication of the object and the replications status of the object (as indicated in the system metadata) is set to QUEUED. Successful completion of this operation is indicated by a HTTP response status code of 200. Unsuccessful completion of this operation MUST be indicated by returning an appropriate exception. The nodeRef, status, and failure parameters are transmitted as part of the HTTP request body encoded as a MIME Multipart/form-data encoded payload.
PUT /replicaMetadata/{pid}	CNReplication.updateReplicationMetadata()	Replaces the replica with matching nodeRef in the system metadata of the specified object. Adds a new replica if the nodeRef of passed in Replica is not already present. Changes the date sys meta modified. Successful completion of the operation is indicated by returning a HTTP status of 200. Failure of the operation MUST be indicated by returning an appropriate exception.
PUT /replicaPolicies/{pid}	CNReplication.setReplicationPolicy()	Updates the replication policy entry for an object by updating the system metadata. Successful completion of the operation is indicated by returning a HTTP status of 200. Failure of the operation MUST be indicated by returning an appropriate exception.
GET /replicaAuthorizations/{pid}?targetNodeSubject={targetNodeSubject}	CNReplication.isNodeAuthorized()	Verifies that a replication event was initiated by a CN by comparing the target node’s identifiying subject with a known list of scheduled replication tasks. Successful completion of the operation is indicated by returning a HTTP status of 200. Failure of the operation MUST be indicated by returning an appropriate exception.
PUT /removeReplicaMetadata/{pid}	CNReplication.deleteReplicationMetadata()	Removes the replication information for the specified node from the object system metadata identified by pid. Removal of replication metadata is necessary if the Member Node goes offline permanently or for an extended period, or when it is deeemed prudent to migrate an object from one node to another to address resource management issues. This method is normally only called by Coordinating Nodes.
PUT /node/{nodeid}	CNRegister.updateNodeCapabilities()	For updating the capabilities of the specified node. Most information is replaced by information in the new node, however, the node identifier, nodeType, ping, syncrhonization.lastHarvested, and synchronization.lastCompleteHarvest are preserved from the existing entry. Services in the old record not included in the new Node will be removed. Successful completion of this operation is indicated by a HTTP response status code of 200. Unsuccessful completion of this operation MUST be indicated by returning an appropriate exception.
POST /node	CNRegister.register()	Register a new node in the system. If the node already exists, then a IdentifierNotUnique exception MUST be returned.