Should top-level self links include unsupported query parameters?

As discussed in


the top level “self” link should contain the the link that generated the current response document.

But what about unsupported parameters?

Let´s say there is an optional custom parameter which is not supported anymore but a client sends that parameter in the request.

GET /myResource?optionalLegacyParam=true

How should the server handle that situation?

  • should the server ignore the parameter but include it in the top level “self” link?
    I mean - it´s part of the URL that generated the response. Although it was not used bythe server.
  • should the server ignore the parameter and exclude it in the top level “self” link?
    That could be confusing for the client if the “self” link does not match the requested URL and may violate the principle of least suprise.
  • should the server respond with 400 Bad Request?
    On the one hand, this would violate the robustness principle (be liberal in what you accept)
    On the one hand the specification states that unsupported query parameters should be rejected (at least those which don´t follow the naming conventions?)

What do you recommend?

“Be liberal in what you accept” does not mean to ignore unrecognized parameters, especially if they used to be meaningful.

If a client is sending something that isn’t supported, regardless of whether it used to be supported, it means they may be expecting some response other than what you’re returning. It is always better to return a specific, explicit error than to return something that will be misinterpreted. It may not be convenient for the client, but with distributed systems, maintaining integrity is essential.



Thanks for your thoughts!