You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The specifications of the apiDocUrl and referenceDocUrl fields of request payload to add a new release are unnecessarily vague. There's no real need for a client to submit a {version} template variable, as it could just send an expanded URL, which would allow the type of the field to be tightened to URL.
A backwards-compatible way of supporting this would be to accept optional fields apiDoc and referenceDoc to only accept URLs if given. This step could also be used to rather let a referenceDocs expect an array of objects, each with an href and type field, to allow different types (HTML, PDF) of reference docs to be submitted.
An apiDoc would then trump apiDocUrl. A referenceDocs would trump a referenceDoc (this one defaulting to a single entry with type to HTML). A canonical response format is described in #2.
The text was updated successfully, but these errors were encountered:
The specifications of the
apiDocUrl
andreferenceDocUrl
fields of request payload to add a new release are unnecessarily vague. There's no real need for a client to submit a{version}
template variable, as it could just send an expanded URL, which would allow the type of the field to be tightened to URL.A backwards-compatible way of supporting this would be to accept optional fields
apiDoc
andreferenceDoc
to only accept URLs if given. This step could also be used to rather let areferenceDocs
expect an array of objects, each with anhref
andtype
field, to allow different types (HTML, PDF) of reference docs to be submitted.An
apiDoc
would then trumpapiDocUrl
. AreferenceDocs
would trump areferenceDoc
(this one defaulting to a single entry withtype
to HTML). A canonical response format is described in #2.The text was updated successfully, but these errors were encountered: