I
Iced lavender Panda
Several APIs make use of other Content-Type values than "application/json".
For example:
  • application/<example>+json (still JSON, just a different Content-Type value)
  • application/x-www-form-urlencoded
  • application/xml
  • application/graphql
  • text/xml
  • text/plain
  • other binary formats
I propose the following:
  • Move Headers before Body in Action and detect usage of Content-Type header in the Action, or add a specific input for Content-Type (remember to allow for any custom Content-Type and usage of encodings, for example "Content-Type: application/x-www-form-urlencoded; encoding=utf-8")
  • Add option to hide headers and parameters with a default value (making them defined in the Custom Integration and not modifyable)
  • Change "JSON Body" to "URL-encoded Body" whenever "Content-Type" is set to "application/x-www-form-urlencoded", presenting the user with a key-value editor
  • Change "JSON Body" to "Body" whenever any other content-type is used, allowing for a text input with Jinja2 support
Notes on "application/x-www-form-urlencoded":
  • Defined in RFC 1738
  • Both keys and values are always strings
  • Values can be interpreted by servers as different types
  • Keys can be interpreted by servers to create objects/arrays
  • Due to different implementations on key formatting for arrays by various servers, I suggest either leaving keys as plain strings or supporting different key encoding schemes:
1. duplicate keys are treated as arrays "array=...&array=..."
2. brackets "array[]=...&array[]=..."
3. indexed brackets "array[0]=...&array[1]=..."