v3.2: Should API URLs in general, and the Server Object url field in particular, still only use the retrieval URL as the base URL

[handrews]

PR #4389 adds $self as the base URI for API Description URIs per RFC3986§5.1.1, and keeps the further process for establishing base URIs in alignment with RFC3986§5.1.2–4.

It does not change the base URI for API URLs, including Server Object urls, and leaves that process looking to the nearest Server Object and then to the containing document's retrieval URL. The only change that PR introduces that would be relevant is the ability to manually supply a retrieval URL (for reasons included in the PR, although see Issue #4540).

Since PR #4389 is not intended to change how API URLs work, if we want to change them based on the new presence of $self that needs its own discussion, which I a starting here.

[handrews]

More relevant commentary from @notEthan:

I certainly agree/understand that the URIs of the API description and objects within are quite different than (or unrelated to) API server/endpoint URLs. My hesitation is on the idea that the retrieval URI for the OAD is likely to be more closely related to the server URL than $self (I've generally seen the OAD served from one place accompanying documentation, not with each deployment, and aren't server variables the better mechanism for deployment-specific URLs?).

Or rather, my hesitation as an implementer of tooling is on whether that difference is worth implementing - I have one base URI for objects in the OAD (including servers), which will be changing to inherit from $self, and no place to put another base URI. It's not difficult to implement but it adds some complexity in a place I have doubts on the real utility of it.