From AST JSON to API Blueprint: References become redundant model data
Initial MD:
### Check if a Gist is Starred [GET]
+ Response 200
[Star][]
Snowcrash Parsed JSON:
{
"name": "Check if a Gist is Starred",
"description": "",
"method": "GET",
"parameters": {},
"headers": {},
"examples": [
{
"name": "",
"description": "",
"requests": [],
"responses": [
{
"name": "200",
"description": "HAL+JSON representation of Star Resource.\n",
"headers": {
"Content-Type": {
"value": "application/hal+json"
},
"Link": {
"value": "<http:/api.gistfox.com/gists/42/star>;rel=\"self\""
}
},
"body": "{\n \"_links\": {\n \"self\": { \"href\": \"/gists/42/star\" },\n },\n \"starred\": true\n}\n",
"schema": ""
}
]
}
]
}
Matter Compiler -> MD again
### Check if a Gist is Starred [GET]
+ Response 200 (application/hal+json)
HAL+JSON representation of Star Resource.
+ Headers
Link: <http:/api.gistfox.com/gists/42/star>;rel="self"
+ Body
{
"_links": {
"self": { "href": "/gists/42/star" },
},
"starred": true
}
Shouldn't it be a link/reference again? [Star][]
@rrarunan
Good point. The issue is you can't tell from AST. You can do some heuristic and assume that when there is a defined model and a payload 100% matches you can use the model. But then you would be in the opposite problem of having models links everywhere even where they weren't.
With that being said I am not against implementing the heuristics and I will be happy to merge such a PR.
Yup, I was thinking the same thing, it would be great when you have the Traits done. Because, the use case for this one was that I was appending random body payload using a simulator in the api blueprint so that my mock server would be dynamic. So, now when compiling back to MD after changing the JSON, I should either generate the body twice or have some kind of heuristic based approach, it could be an option maybe.. I would rather have the links and a smaller MD file than having my body be replicated in several places. Thanks!