.. include:: api_substitutions.txt Coordinating Node APIs ---------------------- The service interfaces described here are exposed through the Coordinating Node REST interface to support interactions with Member Nodes and DataONE clients. .. contents:: :local: :depth: 1 .. The following table provides a list of API methods exposed by Coordinating Nodes. :Tier: The tier in which a method is grouped. :Version: Version of API method is available. The lowest version number indicates when the method was added. A version number in parentheses indicates the method is available in that version and is unchanged from the previous version. If more than one version number is present, then the method signature or functionality has changed between API versions. e.g. "1.0, 2.0" indicates that the method was first introduced in Version 1.0 and has been modified in Version 2.0. :REST: The HTTP method and path relative to the Base URL. Parameters specified in the URL are indicated by braces. Note that parameters included in a path MUST be properly path encoded, and parameters included as key, value pairs MUST also be properly encoded. :Function: The function name, associated with an API grouping. :Parameters: Indicates the parameters used when calling the method (sent in the message payload) and the return type. .. include:: generated/generated_CN_function_table.txt ---- Diagnostic API ~~~~~~~~~~~~~~ |CN| operations to assist clients with diagnosing authentication and content formatting. .. autofuncsummary:: CNDiagnostic :functions: :nosignatures: .. automodule:: CNDiagnostic :members: :undoc-members: :show-inheritance: ---- Core API ~~~~~~~~ Core operations necessary for basic interaction with |CN|\s. .. autofuncsummary:: CNCore :functions: .. automodule:: CNCore :members: :undoc-members: :show-inheritance: ---- Read API ~~~~~~~~ The *CNRead* API implements methods that enable object retrieval operations on a |CN|. It includes searches of science metadata and system metadata and exposes log records held by CNs. .. autofuncsummary:: CNRead :functions: .. automodule:: CNRead :members: :undoc-members: :show-inheritance: ---- View API ~~~~~~~~ View operations to see formatted versions of metadata and data for CNs. The *CNView* API implements methods that enable viewing content on a |CN|. Like the MNView service, the CNView service provides a transformed view of a metadata file, data file, or package. The CNView service provides a default view for all content, and may choose to redirect a review request to the authoritative Member Node for a given PID. .. autofuncsummary:: CNView :functions: .. automodule:: CNView :members: :undoc-members: :show-inheritance: ---- Authorization API ~~~~~~~~~~~~~~~~~ Methods for authorization and access control. .. autofuncsummary:: CNAuthorization :functions: .. automodule:: CNAuthorization :members: :undoc-members: :show-inheritance: ---- Identity API ~~~~~~~~~~~~ Methods for account management and identity mapping. .. autofuncsummary:: CNIdentity :functions: .. automodule:: CNIdentity :members: :undoc-members: :show-inheritance: ---- Replication API ~~~~~~~~~~~~~~~ Supports operations for replication of content between Member Nodes. The Data Replication API operates in conjunction with the :mod:`MNReplication` API to assist with the replication of data and science metadata content between Member Nodes to ensure that copies of data and metadata can be retrieved from more than one Member Node where possible. .. autofuncsummary:: CNReplication :functions: .. automodule:: CNReplication :members: :undoc-members: :show-inheritance: ---- Register API ~~~~~~~~~~~~ Register nodes and their capabilities, retrieve node list. The register API methods are used to maintain a registry of nodes participating in the DataONE infrastructure. Note that the node registry is much the same as the Object collection with a restriction on the returned object formats to be Member Nodes or Coordinating Nodes. It may be prudent for the implementation of the registration API to leverage the existing functionality of the object collection rather than implementing a parallel data store. In this case, the "science metadata" could be a DC description of the node, and the "data" might be the detailed registration information including node capabilities, scheduling and so forth. .. autofuncsummary:: CNRegister :functions: .. automodule:: CNRegister :members: :undoc-members: :show-inheritance: