htsget service-info spec should specify POST request support

[andersleung]

Adding a boolean field specifying POST request support to the htsget object returned by the htsget service-info endpoint would allow clients to determine whether they can use the new POST request or they should fall back to multiple GET requests.

If adding a field to the spec isn't ideal, some other method for determining POST request support would still be useful. My use case for this is in adding POST request support to htsjdk, where ideally we'd like to be able to hit the service-info endpoint for a resource once before making any requests to determine which strategy for multi-interval requests to use.

@jb-adams @mlin @lbergelson

[jmarshall]

Probably the best JSON representation for this would be a "methods": ["GET", "POST"] entry in an appropriate part of the service-info response.

However IMHO it's not particularly necessary because:

1. POST support can likely be inferred from the htsget version reported via Content-Type in responses;
2. POST support can be determined in at most one round trip per server: try the query with POST, if you get a 501 response you know all further requests must be via GET;
3. Maintained servers will likely rapidly come to support POST anyway.

[mlin]

Q: is there a general use for service-info to describe available request methods for a given endpoint? or is this an htsget-specific wrinkle?

[jmarshall]

There is nothing related in the generic part of the service-info response at present. This isn't really htsget-specific so perhaps there should be, though it seems to me that the existing generic properties are all much more abstract than this very concrete piece of information. I didn't see anything related to HTTP request methods in the existing ga4gh-service-info issues; perhaps we should ask the question over there.