Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add docs for deserialization of ambiguous query params #1080

Merged
merged 1 commit into from
Feb 4, 2022
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 10 additions & 0 deletions docs/source/1.0/spec/core/http-traits.rst
Original file line number Diff line number Diff line change
Expand Up @@ -924,6 +924,10 @@ request:
example, given a member bound to ``foo`` that targets a list of strings
with a value of ``["a", "b"]``, the value is serialized in the query string
as ``foo=a&foo=b``.
* When deserializing, server implementations SHOULD use the first encountered
value in the query string for non-collection members. For example, given a
member bound to ``foo`` that targets a string and a query string of
``foo=a&foo=b``, the deserialized value of ``foo`` should be ``a``.

.. important:: Percent-encoding is an implementation detail

Expand Down Expand Up @@ -1018,6 +1022,12 @@ target map will be serialized in the request query string. Key-value pairs in th
are treated like they were explicitly bound using the :ref:`httpQuery-trait`, including the
requirement that reserved characters MUST be percent-encoded_.

When servers deserialize the query string into a ``map`` of ``string``, they SHOULD take the
first encountered value for each key. Since this rule applies to all future query string
values, and changing from a ``map`` of ``string`` to a ``map`` of ``list`` of ``string`` is
backwards-incompatible, care should be taken to use ``map`` of ``string`` only when it is
certain that multiple values for any query string will never be meaningful for the operation.

If a member with the ``httpQueryParams`` trait and a member with the :ref:`httpQuery-trait`
conflict, clients MUST use the value set by the member with the :ref:`httpQuery-trait` and
disregard the value set by ``httpQueryParams``. For example, given the following model:
Expand Down