Skip to content

Loading…

Normalize MediaType to allow params matching #1

Closed
seancribbs opened this Issue · 0 comments

1 participant

@seancribbs
Webmachine member

Currently the body-producing method is chosen solely on the negotiated media type, but ignores params. For cases of parameterized types (except charset), we need to match more specifically. This will allow people to provide different representations that are the same major type but hinged on the parameters.

Example: (API versioning)

Accept: application/json;version=3, application/json;version=1;q=0.7, */*;q=0.5

Tasks:

  1. Move MediaType out of Conneg to top-level.
  2. Add a method that matches the entire type but ignores charset.
  3. Upgrade MediaType.parse to recognize the [String, Hash] form and instances of itself.
@seancribbs seancribbs added a commit that closed this issue
@seancribbs seancribbs Match media types less strictly. Closes #1.
Media types are now matched at the level specified by the client. That
is, a response type may be negotiated that is MORE
specific (containing more type parameters) than requested by the
client in the Accept header.  This also applies to
content_types_accepted, meaning that an incoming entity may be
accepted by a less-specific processing method.

This will have less-surprising behavior when a client requests an
unparameterized type but the resource only provides parameterized
ones, as well as supporting patterns like versioned APIs via the type
parameters.
3686d0d
@ian-plosker ian-plosker referenced this issue
Commit has since been removed from the repository and is no longer available.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.