FORMAT: 1A
HOST: https://cold.pizza
# Some API
# Root [POST /foo]
+ Request (application/xml)
+ Attributes (foo)
+ Body
<?xml version="1.0" encoding="UTF-8"?>
<foo>
<bar>something</bar>
</foo>
+ Response 200 (application/xml)
+ Attributes (result)
+ Body
<?xml version="1.0" encoding="UTF-8"?>
<result>
<status>OK</status>
</result>
## Data Structures
### `result`
- result (status, required)
### `status`
- status: OK (string, required)
### `foo`
- foo (required, bar)
### `bar`
- bar: woof (required, string)
When rendered using the default template (is this different with any others?) both the request and the response elements render the body as JSON instead of XML, even though the content-type header is correctly detected.
Note also that the example string for the rendered body ("woof") is taken from the Data Structures section instead of the provided Body (in which case it would be "something").
I propose two changes to fix this:
Generate a request body from the attributes only when no Body has been provided already (we can assume that if the user provided one it's because they wanted it).
When generating a body, take into consideration what the content-type is for that request. There are probably too many to get it right, but we could definitely do better than forcing everything to use JSON no matter what.
Take a simple document like this one:
When rendered using the default template (is this different with any others?) both the request and the response elements render the body as JSON instead of XML, even though the
content-typeheader is correctly detected.Note also that the example string for the rendered body (
"woof") is taken from theData Structuressection instead of the provided Body (in which case it would be"something").I propose two changes to fix this:
Generate a request body from the attributes only when no Body has been provided already (we can assume that if the user provided one it's because they wanted it).
When generating a body, take into consideration what the content-type is for that request. There are probably too many to get it right, but we could definitely do better than forcing everything to use JSON no matter what.