v3.2: Allow Media Type and Encoding re-use #4728
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add the Media Type Object and Encoding Object to the Components Object, and allow a Reference Object anywhere they are allowed. To ensure that re-usable Objects can be documented clearly, add a
description
field to both Objects. [Note: If addingdescription
is more controversial than just supporting re-use, I could be persuaded to drop it.]One important thing to do as a release approaches is to try to use the new features more. As I have done this, I've realized that our increased usage and functionality of Media Type and Encoding Objects (which now handle streaming JSON, and are expected to handle a wider variety of multipart media types and be more useful with XML) make re-use of those objects a much more compelling prospect. While your average
application/json
Media Type Object is trivial, once you start using more complex media types, the duplication becomes substantial.Explanation and Examples
One use case might come from @jeremyfiel who, IIRC, works with an API where
multipart/mixed
usage that combines JSON metadata with binary data is common. Depending on how complex and common that format is, the media type object might be worth re-using in many places. We're expanding the support formultipart
a lot, and in generalmultipart
Media Type Objects are quite complex, with many Encoding Objects (which may have substantial commonality themselves if similar parts are used in differentmultipart
configurations) plus Example Objects.But to bring things back to a concrete example, here is a pattern that was at one time fairly common- allowing querying either through the URL query string, or through putting the query contents in the body of a POST in case the URL got too long (although here I am showing QUERY instead of POST).
Assume both of the examples to follow start with these components (I pulled them out to make the length comparisons more obvious):
Here it is with re-use, at 53 additional lines:
Without re-use, it takes 66 additional lines. However, there is another wrinkle if we wanted to put in some descriptive text, which we'll look at afterwards:
These examples are light on describing the query behavior. If we add
description
fields to the above version, we can describe the multi-value behavior of every parameter by adding it to#/components/encodings/OrValuesNoExplode
. But if we want to document that in the non-re-use version, there is nowhere to put it on a per-parameter basis. The Encoding Object does not allow it, and the Schema Object is not really where that description should go as the Schema might be used for other things. So if we really want per-parameter descriptions, we'd have to replace our onein: querystring
parameter with individualin: query
parameters, and now everything is even longer (70 lines, partially because there wasn't any point in having aparameters
components section anymore which reduced the count). And in this version, there's nowhere to put an example of the entire query string, either!