Ultimately, the information that you want to inform the client of is one of API or application policy. There really isn't any standard way to convey this information via HTTP; at least, not today. Unless your clients are savvy, even if you did provide this information, they'd likely ignore it and you're back to 406 or 415.
The best standard way I can think of to negotiate this would require the client to send HEAD first with Accept or Content-Type and then the server responds with OK if allowed or the appropriate 406 or 415. HTTP caching and/or other techniques can be used to minimize the number of negotiations, but in the worst case scenario, there is always two requests.
The next best way would arguably be through policy enforced with API versioning. Although the differences in version would only be by representation, all facets are clearly separated. If API version 1.0 supports application/xml it should stay that way - forever. This provides:
- Stability and predictability for clients
- Should allow you to easily identify clients on the old API (and possibly notify them)
- Keeps things simple on the server
There are also few ways to loosely advertise that a particular API version is being deprecated. You could use standard headers such as pragma or warning, or you can use something like api-deprecated-versions: 1.0, 1.1. This approach still requires a client to pay attention to these response headers and may not necessarily indicate when the API will transition from deprecated to completely sunset. Most mature server API policies would have a deprecation period of 6+ months, but this is by no means a hard and fast rule; you'd have to establish that will your clients. What this approach can do is enable telemetry owned by clients to detect that an API (and/or version) they are using is deprecated. This should alert client developers to determine the next course of action; for example, upgrade their client.
Depending on your versioning semantics, if they even exist, you likely can achieve a similar albeit more optimal approach using OPTIONS. There isn't an Allow-Content-Type complement to Allow, but you could certainly define a custom one. You might also simply report api-supported-versions and api-deprecated-versions this way. This would enable tooling and clients to select or detect an appropriate endpoint and/or media type. A client might use this approach each time its application starts up to detect and record whether the endpoint they are using is still up-to-date.
A final suggestion could be to advertise this information by way of an OpenAPI (formerly Swagger) document. Such a document would indicate the available URLs, parameters, and media types. A client could request the appropriate document to determine whether their API and expected media type are supported.
Hopefully that gives you a few ideas. First, you need to define a policy and decide how that will be conveyed. You'll then need to educate your clients on how to take advantage of that information and capability. If they opt not to honor that information, then caveat emptor - they'll just get 406, 415, or some other appropriate error response.
