topic Re: Working out RESTCONF URLs in Controllers

Working out RESTCONF URLs

ChrisNewnham_ — Fri, 08 Apr 2022 14:06:02 GMT

Hello

Could someone please guide me on the best practise for determining URLs for doing something - e.g. I want to fetch all of the SNMP servers and add a new server.

https://<sandbox>:<port>/restconf/data/?????

Is it possible to do this without the PYANG tool?

Thanks

Re: Working out RESTCONF URLs

bigevilbeard — Sat, 09 Apr 2022 14:15:35 GMT

Hey @ChrisNewnham_ take a look at YANG Suite, https://developer.cisco.com/yangsuite/ IMO a little easier to use the PYANG.

Hope this helps.

Re: Working out RESTCONF URLs

ChrisNewnham_ — Sun, 10 Apr 2022 07:32:12 GMT

Thanks - I'm struggling to work out where the URL ends and the JSON object begins.

For example, I'm trying to add an nssa area to ospf (e.g. area 5).

The correct GET URL is: https://{{device}}:{{port}}/restconf/data/Cisco-IOS-XE-native:native/Cisco-IOS-XE-native:router

But for POSTs: https://{{device}}:{{port}}/restconf/data/Cisco-IOS-XE-native:native/Cisco-IOS-XE-native:router

My payload:

{
        "Cisco-IOS-XE-ospf:router-ospf": {
            "ospf": {
                "process-id": [
                    {
                        "id": 1,
                        "area": [
                            {
                                "area-id": 5,
                                "nssa": {}
                            }
                        ]
                    }
                ]
            }
        }
    }

{
    "errors": {
        "error": [
            {
                "error-message": "object already exists: /ios:native/ios:router/ios-ospf:router-ospf",
                "error-path": "/Cisco-IOS-XE-native:native/router",
                "error-tag": "data-exists",
                "error-type": "application"
            }
        ]
    }
}

The error message:

Re: Working out RESTCONF URLs

bigevilbeard — Mon, 11 Apr 2022 09:02:44 GMT

@ChrisNewnham_ Based on your error there it looks like this config is already present on the device. When you do a POST, you provide the URI for where an instance is going to be created. When you do a PATCH, you provide the URI to the node you want to modify. It's down to the semantics of whether you modify the content in the URI you specify or create an instance on that URI. Whatever URI you provide needs to correspond to the payload that goes along with it - namely, the root of the payload will be different depending on the depth of the URI you provide.

Hope this helps.