Interactive API Docs / POST body data omitted using consumes 'application/x-www-form-urlencoded'
Steps to duplicate:
Take for example this api which defines a method capable of consuming application/x-www-form-urlencoded and text/plain:
https://swaggerhub.com/api/evosus/webapi/1.3.0
POST /method/Inventory_Item_StockSiteQuantity_Get
Enter the 3 required fields as follows:
CompanySN: 20091102165026*177
ticket: d5fef8e5-a3d3-456e-b4a9-5203c947ee97
body: blah blah blah
With parameter content-type set to application/x-www-form-urlencoded and click 'Try this out'. Notice the -d parameter in the curl command is missing.
curl -X POST --header "Content-Type: application/x-www-form-urlencoded" --header "Accept: application/json" "https://cloud3.evosus.com/api/method/Inventory_Item_StockSiteQuantity_Get?ticket=d5fef8e5-a3d3-456e-b4a9-5203c947ee97&CompanySN=20091102165026*177"
With parameter content-type set to text/plain click 'Try this out'. Notice the -d parameter is set properly.
curl -X POST --header "Content-Type: text/plain" --header "Accept: application/json" -d "blah blah blah" "https://cloud3.evosus.com/api/method/Inventory_Item_StockSiteQuantity_Get?ticket=d5fef8e5-a3d3-456e-b4a9-5203c947ee97&CompanySN=20091102165026*177"
Is there something I am doing wrong? Thanks in advance for your assistance.
I got to the bottom of the problem. I can't argue with your observation that I don't have CORS enabled since it was throwing the CORS error. Specifically an error during the preflight request. Preflight is the key word.
A pre-flight request is only associated with a complex CORS request and not a simple CORS request. My request WAS simple when my content-type was x-www-form-urlencoded. When I changed my request to content-type application/json the CORS requirement, by definition, changed to COMPLEX. This is explained in the excellent HTMLRocks CORS topic (http://www.html5rocks.com/en/tutorials/cors/).
I had the CORS headers, as shown above on my POST request. However, the preflight request uses the OPTIONS verb. My web service did not handle the OPTIONS verb. Now it does. Now it works.
Most web service implementations will probably find it easiest to implement the handling of OPTIONS calls using a request filter. Check for the OPTIONS verb and short-circuit the request with a null response prior to route handling. Alternately you can implement an OPTIONS verb in the route handler in addition to your other http verbs. The calling web site only needs to see the proper headers in the response.
Thanks for your support.
