Adjusted language examples to properly display application/x-www-form… #331
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.
This PR provides support for application/x-www-form-urlencoded requests to be displayed properly within the various language examples. The app I'm working with is using Laravel Passport and I was needing a way to display to users how to obtain an access token via the following URL (which uses application/x-www-form-urlencoded under the hood).
https://laravel.com/docs/8.x/passport#retrieving-tokens
I'm not exactly proficient in all of the languages but used my best judgement. Below are some of the before/after screenshots. With the exception of python, application/x-www-form-urlencoded expects parameters instead of json so those are what the adjustments are focused on.
bash (before)
bash (after)
javascript (before)
javascript (after)
php (before)
php (after)
The php demo was hiding the Content-Type header, and I know you (@shalvah) mentioned here (#330) that this is because the Grizzly library that the examples are using automatically add those for you, but I still believe it'd be best to explicitly display those to the users integrating with the documentation. Anything to make it easier right? Plus, the Guzzle docs just mention that Content-Type headers are only set when no Content-Type header is already present. Well in this case one is being explicitly provided and should be displayed. Another part of the issue here, and maybe the bigger part of the issue, was that there was no way to display the body type of "form_params" instead of "json" (which the oauth/token example doesn't work when using json).
https://docs.guzzlephp.org/en/stable/request-options.html#form-params
python (before)
python (after)
Not a python user so I hope is correct.
Thanks for your time!