Looking at draft-ietf-netconf-restconf-13, it looks like the RFC 7320
mechanism is used to find the root URL, from which all the Restconf URLs
are derived by appending path components as specified in the draft.
But looking at RFC 6570, which is referenced by both 7320 and the draft,
it seems like appending path components to a configured base URL is no
longer best practice, because it requires the HTTP server to be able to
connect all those URLs to the Restconf server despite their different
paths. It seems like the new, improved method is for a URL template to
be advertised, and the Restconf client should use the template and the
Restconf specification to construct the URL to be used.
E.g., now, the example in section 3.1 shows how the Restconf root is
obtained:
Request
-------
GET /.well-known/host-meta HTTP/1.1
Host: example.com
Accept: application/xrd+xml
Response
--------
HTTP/1.1 200 OK
Content-Type: application/xrd+xml
Content-Length: nnn
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
<Link rel='restconf' href='/restconf'/>
</XRD>
and used, with the sub-URL "operations":
Request
-------
GET /top/restconf/operations HTTP/1.1
Host: example.com
Accept: application/yang.api+json
RFC 6570 seems to suggest that the first lookup should return a URL
template:
Request
-------
GET /.well-known/host-meta HTTP/1.1
Host: example.com
Accept: application/xrd+xml
Response
--------
HTTP/1.1 200 OK
Content-Type: application/xrd+xml
Content-Length: nnn
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
<Link rel='restconf' href='http://example.com/{resource}'/>
</XRD>
The value of this being that a different server might return the
template 'http://example.com{?resource}', causing the second request to
use the URL 'http://example.com?resource=operations'.
Although this probably requires a redefinition of the href attribute of
the Link element.
Dale
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
