Clarify retrieval of supported protocols for a node

[zonia3000]

The getNode section also describes how to retrieve supported protocols for a node:

The list of supported protocols for a node can be retrieved with:

• A HTTP POST of an empty protocol representation to the URL of an existing node http://rest-endpoint/nodes/path

I think that, as happened for the paginated request, this piece of text could be easily missed.

Moreover it is not very clear what should be the content of the request and the response. I think that moving this to a dedicated subsection and adding a complete example should be preferable.

I also think that using POST method for retrieving data doesn't conform with RESTful semantic.

[Zarquan]

I agree. There are many things wrong with this.

Using POST to get information really does break the RESTful pattern.

It also breaks the core data model. It implies that Protocols are associated with a Node. They aren't. What Protocols are available depends on the transfer direction [PushTo, PullTo, PushFrom, PullFrom] and which View is selected.

For example, I could have FITS files on a server and provide ftp and http download for the raw binary-file view. I could also have a Servlet in the web server that provides a gzip-file view of the file, compressing the data on the fly. In which case, the binary-file view would be available via both ftp and http, but because the compression Servlet is in the web server, the gzip-file view is only available via http.

Does anyone know what the use case is for this ? One that would not be satisfied by POSTing a 'PullFrom' transfer for the binary-file view ?

If not, can we mark this as deprecated in this version, and removed in the next ?

[brianmajor]

I also don't understand that point about POSTing to a node with an empty protocol representation. I also can't think of what it is trying to solve. So fine with me to deprecate/remove it.

[zonia3000]

I'm also in favor of deprecating this one.