|
[as an individual]
I agree that we should strictly avoid synthesizing URLs in general, and should try to avoid .well-known URLs in particular. Sometimes you're forced to use .well-known (e.g., when there's literally no way to get a full URL to the client), but that doesn't seem to be the case here. On 1/14/18 11:39 PM, Martin Thomson wrote: a. use .well-known and just provide better justification for it b. use content negotiation c. find some way to get two URIs, like revising 7710 or finding an alternative mechanism (such as the one in RFC 5986)
For what it's worth, I don't think (a) is possible -- I don't
believe any plausible justification text can be put together that
explains why other approaches are infeasible. Something else to consider is serving up the HTML portal on the endpoint you get from RFC7710, and including a link-relation [RFC5988] header field that points to the API; e.g.:
HTTP/1.1 200 OK <!DOCTYPE html PUBLIC ...
<html>...
[legacy portal page goes here]...
</html>
Importantly: clients interested only in the API can simply
perform a HEAD rather than a GET to retrieve the Link information.
I'll note that this provides a clear extension point if you decide
you need yet a third thing to be discoverable and/or need
different HTTP endpoints for versioning in the future. I do note
that it requires an additional round trip, similar to the
redirection approach that has been discussed in conjunction with
content negotiation. Notably, taking this approach eliminates the
need for redirects, since the link header can point to any
arbitrary URL. /a |