Should top-level self links include unsupported query parameters?

[Jerry87]

As discussed in

Top-level links vs. resource-level links for item resources

In JSON:API, links for item-resources can either be put on top-level or on resource-level. Is there a best practice to prefer the one or the other (or even both)? I am the author of a JSON:API implementation for Spring HATEOAS (https://github.com/toedter/spring-hateoas-jsonapi) I am thinking about making the preferred style configurable. What do you think?

and

Should top-level self links include query params?

Should the top-level self link include the query params (such as filters and sorts)?

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?

[fdrake]

@Jerry87

On the one hand, this would violate the robustness principle (be liberal in what you accept)

“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.

-Fred

[Jerry87]

Thanks for your thoughts!