Accept x-www-form-urlencoded

[joeflateau]

No description provided.

[MikeRalphson]

Thanks for the PR! Interesting idea. Should it be extended to cover multipart/form-data as well? I wonder whether it should be behind an option flag because perhaps most API consumers wouldn't be as concerned with the formatting of formData parameters (because the format is fixed) than they are with xml or json where they may have to format the payload themselves...

[joeflateau]

You're welcome! Thanks for making an awesome project.

form-data would be tough from a formatting perspective (meaning, the example could get LONG). I needed this particular change to document an asp.net api that accepts parameters through the built-in params collection that can accept form-data or x-www-form-urlencoded. I suspect there are very few apis that accept form-data and NOT x-www-form-urlencoded so not sure the extra effort is worth it.

[MikeRalphson]

@joeflateau So this change is only where a schema is defined for a body parameter and the consumes type is application/x-www-form-urlencoded?

I'm slightly confused by where you mention

parameters through the built-in params collection that can accept form-data or x-www-form-urlencoded

Could you possibly share a snippet of the API definition either here or in a gist?

It certainly feels a little niche, but not actually against the OpenAPI 2.0 spec.

[joeflateau]

I'm sorry, that was probably worded confusingly. What I'm saying there is that, in ASP.net you can read "form fields" through a collection. eg: Request.Form["my-field-123"] and it doesn't matter if the HTTP request was multipart/form-data or application/x-www-form-urlencoded you read the fields the same either way. The "params collection" I'm referring to isn't the OpenAPI Spec, it's an ASP.net thing.

[MikeRalphson]

@joeflateau Just chasing up this so I can test it.

Could you possibly share a snippet of the API definition either here or in a gist?

[joeflateau]

@MikeRalphson oh yes, sorry, totally slipped my mind. here you go: https://gist.github.com/joeflateau/cd18db5c6d31cd8aebda47b5583be35b

[MikeRalphson]

@joeflateau Hmm, that swagger definition doesn't seem to be valid according to the specification. Only in:body parameters can have a schema property. Is it possible for you to change the in of the parameters and remove type:object (which is implied), or does that break something else for you?

[joeflateau]

@MikeRalphson seems fine changing in to body and dropping the type property completely.

https://gist.github.com/joeflateau/8e82bcd346b4a862927f4c641da95020

[MikeRalphson]

Hmm, I'm still a bit confused and the second sample still isn't valid Swagger 2.0. Is FbAuthToken really a (JSON) object with a property access_token, or is it a simple form parameter? In the latter case it doesn't need / shouldn't have a schema at all.

[MikeRalphson]

Hi @joeflateau - can you try your definition with the latest version? Request body parameters are now handled differently.

[MikeRalphson]

Closing this for now - structured request body parameters should now be displayed better regardless of the produces/consumes used within v2.0 definitions.