RESTCONF: GET for empty list, is 204 the standard answer?

[rogaglia]

When querying via RESTCONF to NSO for an empty list, NSO returns with 204 NoContent. I was not able to find this behavior in the RFC8040 and I am getting challenged on why not to send 200OK and an empty JSON/XML.

Do we have any clear reference for this behavior?

[perander]

RFC 7950 (YANG 1.1) sheds some light on the behaviour:

7.8.5. XML Encoding Rules 

A list is encoded as a series of XML elements, one for each entry in 
the list. Each element's local name is the list's identifier, and 
its namespace is the module's XML namespace (see Section 7.1.3). 
There is no XML element surrounding the list as a whole.

So when there are no elements, there is nothing to encode. (RFC 7951 JSON Encoding of Data Modeled with YANG doesn't contest this behaviour.)

The RESTCONF behaviour is consistent with e.g. NETCONF and CLI:

$ netconf-console --get -x /jukebox/library
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
  <data>
    <jukebox xmlns="http://example.com/ns/example-jukebox"/>
  </data>
</rpc-reply>

admin@ncs> show jukebox library 
% No entries found.
[ok][2019-10-21 10:51:02]

One way to solve this is to have a choice where the case for empty list is some bogus leaf to indicate an empty list. Otherwise it's impossible to distinguish an empty list from an non-existing list.

[tcragg1]

It may not be in the RESTCONF RFC, but I would argue that it is covered by one of the HTTP RFCs that the RESTCONF RFC depends upon, RFC7231

Specifically regarding 200 OK messages, section 6.3.1 of RFC7231 states "Aside from responses to CONNECT, a 200 response always has a payload, though an origin server MAY generate a payload body of zero length. If no payload is desired, an origin server ought to send 204 (No Content) instead".

I read this as stating that while an empty JSON/XML in a 200 does not violate the standard, a 204 is the preferred way to handle this scenario in the HTTP RFC.