https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/CONTROLLER-474 controller <p>REST and POST should deal with the same URIs and expect data formatted in the same ways. Currently, they seem to treat namespaces differently (I guess; I haven't actually be able to figure out what the actual behavior is)</p> <p>The API as presented in the swagger API explorer is reasonably, sane, telling me I can either POST or PUT into URIs such as /config/toaster:toaster.</p> <p>However, only PUT actually works here, and the semantics are (as correct for PUT) to wipe out everything below that URI and replace it with the new PUT data.</p> <p>Operating System: Linux<br/> Platform: PC</p> CONTROLLER-474

PUT and POST uris and namespaces are inconsistent

Bug Resolved Cannot Reproduce Jozef Gloncak Rob Adams Wed, 14 May 2014 22:19:34 +0000 Tue, 14 Nov 2017 15:17:59 +0000 Tue, 14 Oct 2014 10:57:21 +0000 Helium restconf 0 7 <p>In trying to nail down the expected behavior with post, I looked at the restconf spec:</p> <p><a href="https://tools.ietf.org/html/draft-bierman-netconf-restconf-02#section-3.4" class="external-link" target="_blank" rel="nofollow noopener">https://tools.ietf.org/html/draft-bierman-netconf-restconf-02#section-3.4</a> it states that POST can be used on Datastore, Data, or operations. WE are focused on Datastore / Data with this item.</p> <p>I <b>believe</b> the datastore aspect is working correctly. That is we can POST to /config and update that store as necessary.</p> <p>===</p> <p>Therefore this ticket should be about allowing POST to the "data" resource as defined here: <a href="https://tools.ietf.org/html/draft-bierman-netconf-restconf-02#section-5.3" class="external-link" target="_blank" rel="nofollow noopener">https://tools.ietf.org/html/draft-bierman-netconf-restconf-02#section-5.3</a></p> <p>According to the above restconf spec, it looks like POST is only valid on Containers or Lists.</p> <p>Therefore, my interpretation is that we want the following behavior:</p> <p>POST to /config/&lt;container&gt; should request a "creation" of that resource. Q: What happens if it already exists? Replace? Merge? Fail?</p> <p>POST to /config/&lt;cointainer&gt;/&lt;listId&gt; should request the creation of a node in that list. Q: What happens if the node with the given ID already exists?</p> <p>Also, there are mentions of query parameters. insert / point which should be considered.</p> <p>Some more discussion/etc is required to understand the desired behavior of POST before we can work this ticket.</p> <p>(Feel free to correct any false assumptions I made above.)</p> <p>Since POST to a data resource is "treated as a request to create a resource or sub-resource", I think if it already exists then the "data-exists" error should be returned.</p> <p>PUT is intended "to replace the target resource" so the operation is performed if the resource already exists.</p> <p>I have noticed inconsistencies/differences between POST and PUT in ODL as to what is allowed in the URI and message body. It seems to me they should work the same.</p> <p>Eg, I can PUT:<br/> <a href="http://localhost:8080/restconf/config/toaster:toaster" class="external-link" target="_blank" rel="nofollow noopener">http://localhost:8080/restconf/config/toaster:toaster</a></p> <p>{<br/> toaster: </p> { toasterModelNumber: "123", toasterManufacturer: "GE", toasterStatus: "up" } <p>} </p> <p>But I can't POST the same thing. For POST I have to do:<br/> <a href="http://localhost:8080/restconf/config/" class="external-link" target="_blank" rel="nofollow noopener">http://localhost:8080/restconf/config/</a></p> <p>{<br/> toaster:toaster: </p> { toasterModelNumber: "123", toasterManufacturer: "GE", toasterStatus: "up" } <p>}</p> <p>Hi Tom,</p> <p>Those inconsistencies were the original reason for this bug, though it's definitely good to make sure we have well-defined clean semantics for what the different verbs do.</p> <p>POST as far as I can tell can only go to the root of the config model, and then you also need to format the body of the message differently for some reason. I don't understand why they would be different.</p> <p>I've hit this bug and the differences in URIs are very confusing. </p> <p>BTW, PUT is idempotent. Therefore a create or update is the same for PUT. The final result is always the contents of the PUT request.</p> <p>In section 3.4.1, for a POST, a "target resource type is a Datastore or Data resource". It seems currently we only support POST to a Datastore, therefore the URI must be "/restconf/config" and the input must define the fully-qualified path to the resource.</p> <p>It seems what's missing for POST is allowing a specific target Data resource. Then you would be able to POST or PUT with the same URI and input and the swagger API would be correct. </p> <p>Outside of allowed target resource type, the difference between POST and PUT is that, if the resource already exists, POST should do nothing and return the "data-exists" error tag whereas PUT replaces the resource and returns success.</p> <p>Hi Tom, Rob,</p> <p>I`m re-assigning this bug to our team as we have available resource to continue with it. Pls let me know if you have any comment. Thank you.</p> <p>(In reply to Tom Pantelis from comment #2)<br/> &gt; Since POST to a data resource is "treated as a request to create a resource<br/> &gt; or sub-resource", I think if it already exists then the "data-exists" error<br/> &gt; should be returned.<br/> &gt; <br/> &gt; PUT is intended "to replace the target resource" so the operation is<br/> &gt; performed if the resource already exists.<br/> &gt; <br/> &gt; I have noticed inconsistencies/differences between POST and PUT in ODL as to<br/> &gt; what is allowed in the URI and message body. It seems to me they should work<br/> &gt; the same.<br/> &gt; <br/> &gt; Eg, I can PUT:<br/> &gt; <a href="http://localhost:8080/restconf/config/toaster:toaster" class="external-link" target="_blank" rel="nofollow noopener">http://localhost:8080/restconf/config/toaster:toaster</a><br/> &gt; <br/> &gt; {<br/> &gt; toaster: <br/> &gt; </p> { &gt; toasterModelNumber: "123", &gt; toasterManufacturer: "GE", &gt; toasterStatus: "up" &gt; } <p>&gt; } <br/> &gt; <br/> &gt; But I can't POST the same thing. For POST I have to do:<br/> &gt; <a href="http://localhost:8080/restconf/config/" class="external-link" target="_blank" rel="nofollow noopener">http://localhost:8080/restconf/config/</a><br/> &gt; <br/> &gt; {<br/> &gt; toaster:toaster: <br/> &gt; </p> { &gt; toasterModelNumber: "123", &gt; toasterManufacturer: "GE", &gt; toasterStatus: "up" &gt; } <p>&gt; }</p> <p>It is specified in <br/> 1.4.2.2. Create New Data Resources<br/> and <br/> 1.4.2.3. Replace an Existing Data Resource<br/> that PUT and POST should work like this</p> <p>I passed through this discussion. There is several suggestions but is there any definitive conclusion about what should be implemented or fixed?</p> <p>My comments inlines.<br/> (In reply to Devin Avery from comment #1)<br/> &gt; In trying to nail down the expected behavior with post, I looked at the<br/> &gt; restconf spec:<br/> &gt; <br/> &gt; <a href="https://tools.ietf.org/html/draft-bierman-netconf-restconf-02#section-3.4" class="external-link" target="_blank" rel="nofollow noopener">https://tools.ietf.org/html/draft-bierman-netconf-restconf-02#section-3.4</a> it<br/> &gt; states that POST can be used on Datastore, Data, or operations. WE are<br/> &gt; focused on Datastore / Data with this item.<br/> &gt; <br/> &gt; I <b>believe</b> the datastore aspect is working correctly. That is we can POST<br/> &gt; to /config and update that store as necessary.<br/> &gt; <br/> &gt; ===<br/> &gt; <br/> &gt; Therefore this ticket should be about allowing POST to the "data" resource<br/> &gt; as defined here:<br/> &gt; <a href="https://tools.ietf.org/html/draft-bierman-netconf-restconf-02#section-5.3" class="external-link" target="_blank" rel="nofollow noopener">https://tools.ietf.org/html/draft-bierman-netconf-restconf-02#section-5.3</a><br/> &gt; <br/> &gt; According to the above restconf spec, it looks like POST is only valid on<br/> &gt; Containers or Lists.<br/> &gt; <br/> &gt; Therefore, my interpretation is that we want the following behavior:<br/> &gt; <br/> &gt; POST to /config/&lt;container&gt; should request a "creation" of that resource. Q:<br/> &gt; What happens if it already exists? Replace? Merge? Fail?<br/> Currently this works (I tested in POSTMAN and swager. In BrokerFacade is called merge datastore operation.<br/> &gt; <br/> &gt; POST to /config/&lt;cointainer&gt;/&lt;listId&gt; should request the creation of a node<br/> &gt; in that list. Q: What happens if the node with the given ID already exists?<br/> This also works. Behavior is still the same (merge operation)<br/> &gt; <br/> &gt; Also, there are mentions of query parameters. insert / point which should be<br/> &gt; considered.<br/> As I know insert and point parameters aren't implemented. Place where to insert data is specified via URI. BTW I do not understand what is difference between insert and point.<br/> &gt; <br/> &gt; Some more discussion/etc is required to understand the desired behavior of<br/> &gt; POST before we can work this ticket.<br/> &gt; <br/> &gt; (Feel free to correct any false assumptions I made above.)</p> <p>Good question. I recall my confusion was when I was able to PUT to /config/toaster:toaster but not POST, however it's working as defined in the RFC. </p> <p>It sounds like you tested POST to a data resource and it works - I think that wasn't working when this bug was created.</p> <p>Rob mentioned that the swagger UI presented invalid POST urls (e.g. /config/toaster:toaster). If that's still the case then I think swagger should be fixed. Other than that, I would say close this bug.</p> <p>(In reply to Jozef Gloncak from comment #8)<br/> &gt; I passed through this discussion. There is several suggestions but is there<br/> &gt; any definitive conclusion about what should be implemented or fixed?</p> <p>I tested POST in swagger. My results are as follows.</p> <p>YANG container or list which contains can have as subchild:</p> <ul class="alternate" type="square"> <li>case1: one container or list</li> <li>case2: several container or list</li> </ul> <p>case1<br/> =====<br/> I successfully <br/> POST-ed data via toaster POST swager link with following data<br/> {<br/> "toaster": </p> { "darknessFactor": 1 } <p>}</p> <p>case2<br/> =====<br/> It was necessary somehow present collection of all subchild lists and container to one swagger POST link. <br/> For example opendaylight-inventory swagger POST link /config/opendaylight-inventory:nodes/node/</p> {id}/ contains at top level JSON object (config)nodePOST. POST suffix tells that this json object contains list of all possible POSTs for this URI. Here is this json<br/> <br/> (config)nodePOST {<br/> switch-features (object<span class="error">&#91;(config)switch-features&#93;</span>, optional),<br/> supported-actions (object<span class="error">&#91;(config)supported-actions&#93;</span>, optional),<br/> meter (array<span class="error">&#91;(config)meter&#93;</span>, optional),<br/> meter-features (object<span class="error">&#91;(config)meter-features&#93;</span>, optional),<br/> group-features (object<span class="error">&#91;(config)group-features&#93;</span>, optional),<br/> supported-instructions (object<span class="error">&#91;(config)supported-instructions&#93;</span>, optional),<br/> table (array<span class="error">&#91;(config)table&#93;</span>, optional),<br/> supported-match-types (object<span class="error">&#91;(config)supported-match-types&#93;</span>, optional),<br/> group (array<span class="error">&#91;(config)group&#93;</span>, optional),<br/> node-connector (array<span class="error">&#91;(config)node-connector&#93;</span>, optional),<br/> pass-through (object<span class="error">&#91;(config)pass-through&#93;</span>, optional)<br/> }<br/> <br/> It means that from swagger POST link /config/opendaylight-inventory:nodes/node/{id} <p>/ can be posted containers and lists</p> <ul class="alternate" type="square"> <li>switch-features</li> <li>supported-actions</li> <li>....</li> <li>pass-through</li> </ul> <p>This container and lists are detailed specified below this JSON object</p> <p>Then there is in swagger POST link /config/opendaylight-inventory:nodes/node/</p> {id} <p>/ section Parameters which contains:</p> <ul class="alternate" type="square"> <li>id - it is value of key for yang list node</li> <li>several rectangles which name always start with **. It means that one of this rectangle has to be filled.</li> </ul> <p>I tested:</p> <ul class="alternate" type="square"> <li>id - 40</li> <li>**(config)node-connector -<br/> {<br/> "opendaylight-inventory:node-connector": { "id":"id43" } <p>}<br/> INSERTING WAS SUCCESSFUL</p></li> </ul> <p>I specified</p> <ul class="alternate" type="square"> <li>id - 41</li> <li>**(config)meter-features<br/> {<br/> "netconf-node-inventory:pass-through":{<br/> }<br/> }</li> </ul> <p>INSERTING WAS SUCCESSFUL</p> <p>after getting data from via swagger GET link /config/opendaylight-inventory:nodes<br/> I got<br/> {<br/> "nodes": {<br/> "node": [<br/> </p> { "id": "controller-config" } <p>,<br/> {<br/> "id": "40",<br/> "node-connector": [</p> { "id": "id40" } <p> ]<br/> },<br/> {<br/> "id": "41",<br/> "netconf-node-inventory:pass-through": {}<br/> }<br/> ]<br/> }<br/> }</p> <p>So I think that POST-ing data via swager works.</p> <p>Originally I suggested to generate standalone POST links for every child which wasn't accepted (see <a href="https://bugs.opendaylight.org/show_bug.cgi?id=932" class="external-link" target="_blank" rel="nofollow noopener">https://bugs.opendaylight.org/show_bug.cgi?id=932</a> comment 4). </p> <p>I can't see any problem here. So if nobody will point to some other problem I will close this bug next week. Thanks</p> <p>No other problems were reported so I closed the bug.</p> Development External issue ID 1012 External issue URL ODL SR Target Milestone Rank 0|i02kmf: