@Pchelolo, @mobrovac, @Eevans, @ssastry, @Arlolra, @cscott, @Krenair: Does this sound like a sensible change to you?

I support moving to JSON, which is already implicitly supported in RESTBase anyway. As for the validation, since the sections stanza is an object with arbitrary keys, all we can validate here is that if the sections stanza is present, it is indeed an object with one or more keys. But that should be enough to reject ill-formatted requests.

Actually, since sectionIDs are not completely arbitrary, but follow a specified pattern, we could do even more:

schema:
  type: 'object'
  properties:
    sections:
      type: 'object'
      patternProperties:
        '^mw\w+$':
          type: 'string'
      additionalProperties: false
  additionalProperties: false
  required: 
    - sections

However, the validation error message, produced by the schema validator (which we don't control) could be a bit confusing in case section ID doesn't match a pattern:

data.body.sections['asdcmwAg'] should NOT have additional properties

Anyway, all of this would be possible only when we deprecate and remove form-data support.

@mobrovac, @Eevans, pchelolo: Let's do this, then?

I'm all for that, but shouldn't we make an announcement, log users etc. prior to the change?

For this API, losing the POST parameter form fields in the swagger docs shouldn't be an issue. This could be an issue for the more general T111748, though. In particular, HTML transform forms currently provide a text entry field, which is useful for testing & quick ad-hoc conversions.

@GWicke ye, but html transform endpoint doesn't need changes since the value of the POST parameter there is string, not JSON object.