Fails to parse every Apiary API Blueprint

[zdne]

If a blueprint starts with metadata (as most of blueprints from documentation, tutorials and apiary do) the /parse endpoint fails to parse them properly

cURL example

Call

curl --include -X POST https://apiblueprintapi.apiary-proxy.com/parser --header "Content-Type:text/vnd.apiblueprint+markdown; version=1A" --header "Accept:application/vnd.apiblueprint.parseresult.raw+json" -d 'Format: 1A\n\n # API Name\n'

Actual Output

{
  "ast": {
    "_version": "2.0",
    "metadata": [
      {
        "name": "Format",
        "value": "1A\\n\\n # API Name\\n"
      }
    ],
    "name": "",
    "description": "",
    "resourceGroups": []
  },
  "warnings": [],
  "error": null,
  "_version": "1.0"
}

Correct Output

{
  "ast": {
    "_version": "2.0",
    "metadata": [
      {
        "name": "FORMAT",
        "value": "1A"
      }
    ],
    "name": "API Name",
    "description": "",
    "resourceGroups": []
  },
  "warnings": [],
  "error": null,
  "_version": "1.0"
}

[Almad]

@zdne But that isn't in the spec and it's not parsed correctly by snowcrash/protagonist as well.

Correct metadata input is FORMAT: 1A (uppercased)

[Almad]

Works for me:

arael:apiblueprintorg almad$ curl --include -X POST https://apiblueprintapi.apiary-proxy.com/parser --header "Content-Type:text/vnd.apiblueprint+markdown; version=1A" --header "Accept:application/vnd.apiblueprint.parseresult.raw+json" -d 'FORMAT: 1A        > # API Name 
> '
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Content-Type, Accept
Access-Control-Allow-Methods: POST, GET
Access-Control-Allow-Origin: apiblueprint.org
Access-Control-Expose-Headers: Content-Type, Accept
Access-Control-Max-Age: 86400
Content-Type: application/vnd.apiblueprint.parseresult.raw+json; version=1.0
Date: Fri, 18 Jul 2014 11:41:45 GMT
Server: Cowboy
Vary: Accept-Encoding
Via: 1.1 vegur
X-Apiary-Ratelimit-Limit: 120
X-Apiary-Ratelimit-Remaining: 116
X-Apiary-Transaction-Id: 53c907f967297d020000d9bb
X-Parser-Time: 0 s, 1 ms
Content-Length: 169
Connection: keep-alive

{"ast":{"_version":"2.0","metadata":[{"name":"FORMAT","value":"1A"}],"name":"API Name","description":"","resourceGroups":[]},"warnings":[],"error":null,"_version":"1.0"}

[Almad]

For the record, works directly against the API as well:

arael:apiblueprintorg almad$ curl --include -X POST https://api.apiblueprint.org/parser --header "Content-Type:text/vnd.apiblueprint+markdown; version=1A" --header "Accept:application/vnd.apiblueprint.parseresult.raw+json" -d 'FORMAT: 1A
# API Name
'
HTTP/1.1 200 OK
Server: Cowboy
Connection: keep-alive
Date: Fri, 18 Jul 2014 11:43:14 GMT
Vary: Accept-Encoding
Content-Length: 169
Content-Type: application/vnd.apiblueprint.parseresult.raw+json; version=1.0
X-Parser-Time: 0 s, 2 ms
Access-Control-Allow-Origin: apiblueprint.org
Access-Control-Max-Age: 86400
Access-Control-Expose-Headers: Content-Type, Accept
Access-Control-Allow-Headers: Content-Type, Accept
Access-Control-Allow-Methods: POST, GET
Access-Control-Allow-Credentials: true
Via: 1.1 vegur

{"ast":{"_version":"2.0","metadata":[{"name":"FORMAT","value":"1A"}],"name":"API Name","description":"","resourceGroups":[]},"warnings":[],"error":null,"_version":"1.0"}

[zdne]

For the record:

Correct metadata input is FORMAT: 1A (uppercased)

Good point, however it (lowercase or not) has no impact – metadata can be any sort of key: value pair regardless of the casing.

[zdne]

Update: It looks as this is problem with cURL and data input, will investigate

[zdne]

Indeed --data-binary is the trick (not -d) to send the verbatim file

curl --include -X POST https://apiblueprintapi.apiary-proxy.com/parser --header "Content-Type:text/vnd.apiblueprint+markdown; version=1A" --header "Accept:application/vnd.apiblueprint.parseresult.raw+json" --data-binary @apiary.apib