The PUT RESTCONF method represents "create" or "replace" NETCONF operation. 


Both the POST and PUT methods can be used to create data resources. The difference is that for POST, the client does not provide the resource identifier for the resource that will be created. The target resource for the POST method for resource creation is the parent of the new resource. The target resource for the PUT method for resource creation is the new resource.


For example, to create a new list entry with two keys using PUT method the following request could be used:

      PUT /restconf/data/modname:list.1=fred,1 HTTP/1.1
      Host: example.com
      Content-Type: application/yang-data+json

      {
          "list.1": {
              "string.1" : "fred",
              "uint32.1": 1
        }
      }


Resource Types That Support PUT
Type
Description
Datastore
Replace the entire contents of the datastore
Data
Replace that data resource within the datastore


A PUT on the datastore resource is used to replace the entire contents of the datastore. A PUT on a data resource only replaces that data resource within the datastore.  Refer to PUT on datastore article on how to use PUT on Datastore.


The "insert" and "point" query parameters are supported by the PUT method for data resources. These parameters are only allowed if the list or leaf-list is "ordered-by user". Refer to How do I insert or move list entries?


The query parameters are not allowed for the requests for datastore resource.


If the target resource represents a YANG leaf-list, then the PUT method MUST NOT change the value of the leaf-list instance.

Thus, the PUT method on leaf-list nodes will result in a new leaf-list entry creation. For example, the following request could be used to create a new leaf-list entry:

 

      PUT /restconf/data/ietf-interfaces:interfaces/interface=vlan1/untagged-ports \
             HTTP/1.1
      Host: example.com
      Content-Type: application/yang-data+json

      {
          "untagged-ports": [
              "chanel2"
          ]
      }



List Example:

An "album" child resource defined in the "example-jukebox" YANG module is replaced, or it is created if it does not already exist.


If the target resource represents a YANG list instance, then the key leaf values, in message-body representation, MUST be the same as the key leaf values in the request URI. The PUT method MUST NOT be used to change the key leaf values for a data resource instance.


To replace the "album" resource contents, the client might send the following:


      PUT /restconf/data/example-jukebox:jukebox/\
          library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1
      Host: example.com
      Content-Type: application/yang-data+json

      {
        "example-jukebox:album" : [
          {
            "name" : "Wasting Light",
            "genre" : "example-jukebox:alternative",
            "year" : 2011
          }
        ]
      }

If the resource is updated, the server might respond as follows:


      HTTP/1.1 204 No Content
      Date: Thu, 26 Jan 2017 20:56:30 GMT
      Server: example-server
      Last-Modified: Thu, 26 Jan 2017 20:56:30 GMT
      ETag: "b27480aeda4c"


The same request is shown here using XML encoding:


      PUT /restconf/data/example-jukebox:jukebox/\
          library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1
      Host: example.com
      Content-Type: application/yang-data+xml

      <album xmlns="http://example.com/ns/example-jukebox"
             xmlns:jbox="http://example.com/ns/example-jukebox">
        <name>Wasting Light</name>
        <genre>jbox:alternative</genre>
        <year>2011</year>
      </album>


Refer to the following link for an example using the PUT method to replace the contents of the datastore resource:

PUT on datastore


For more details refer to RESTCONF [RFC8040]