The restconf program has the following features:

  • Complete implementation of RESTCONF protocol, defined by IETF RFC 8040.

  • Completely new framework

  • Automatic support for all NETCONF operations, including the YANG 'insert' operation.

  • Supports the complete HTTP/1.1 transport defined in RFC 7230.

  • Complete XML 1.0 implementation with full support for XML Namespaces

  • Complete JSON implementation

  • Automatic support for all capability registration and <hello> message processing

  • Fully recoverable, automatic database editing, using a simple 3 phase callback model

    1. validate

    2. apply

    3. commit or rollback

  • Full support for database locking, editing, validation, including extensive user-callback capabilities to support device instrumentation.

  • Complete <rpc-error> reporting support, including user-defined errors via YANG error-app-tag and error-message statements.

  • Several <rpc-error> extensions, including <bad-value> and <error-number>, for easier debugging

  • Extend error handling

    • HTTP status-lines are used to report success or failure for RESTCONF operations.

    • Error information is returned for "4xx" class of status codes.

    • This error information is adapted for use in RESTCONF.

  • Complete RFC 5277 Notification support, including notification replay via SSE W3C Working Draft

  • Complete RFC 7895 Yang Module Library support, including full support of the YANG modules schema retrieval from the server and support of server-specific identifier representing the current set of modules and submodules.

  • Support new query parameters:

    • The "depth" parameter is used to limit the number of levels of child resources that are returned by the server for a GET method request.

    • The "content" parameter is used to select the type of data child resources (configuration or not configuration, or all data) that are returned by the server for a GET method request.

    • The “with-defaults” parameter is used to select the type of data (report-all, report-all-tagged, trim, explicit) that are returned by the server for

  •   Support GET on /restconf/data

    • This mandatory resource represents the combined configuration and operational data resources that can be accessed by a client. It cannot be created or deleted by the client.

  • Support POST /restconf/operations

    • This optional resource is a container that provides access to the data-model specific protocol operations supported by the server.

    • The server may omit this resource if no data-model specific operations are advertised.

    • Any data-model specific operations defined in the YANG modules advertised by the server may be available as child nodes of this resource.

  • RESTCONF capability support /restconf/data/restconf-state

    • RESTCONF provides the YANG module capability information supported by the server, in case the client wants to use it.

    • The URIs for custom protocol operations and datastore content are predictable, based on the YANG module definitions.

  • Support for new POST and PUT/create operations

    • Support POST/PUT Request based on query parameters and protocol

  • Two "edit collision detection" mechanisms are provided in RESTCONF, for datastore and data resources. Timestamps and Entity Tag.

  • Support full conformance

    • Support Accept header validation
    • Support .well-known. The root of the RESTCONF API configured on the HTTP server, discovered by getting the ".well-known/host-meta"
    • Support ietf-restconf-monitoring
    • Supports notifications that populate a stream resource for each notification delivery service access point. A RESTCONF client can retrieve the list of supported event streams from a RESTCONF server using the GET operation on the /restconf/data/restconf-state/stream list.
    • Supports a new event stream resource. This resource represents an SSE (Server-Sent Events) event stream. The content consists of text using the media type "text/event-stream",

      as defined by the HTML5 specification. Each event represents one <notification> message generated by the server. It contains a conceptual system or data-model specific event that is delivered within an event notification stream. Also called a "stream resource".