damn-api sample spec

api_spec.json

{
  "host": ["api.example.com", "api-staging.example.com"],
  "headers": { // By default, optional: false
    "X-EXAMPLE-DEVICE-TYPE": ["iphone", "android"],
    "X-EXAMPLE-DEVICE-UUID": {
      "value": "mock",
      "optional": true
    },
    "X-EXAMPLE-APP-ID": ["com.example.iphone.app1", "com.example.iphone.app2", "com.example.android.app1"]
  },
  "api_groups": [
    {
      "name": "Account API",
      "apis": [
        {
          "name": "Account Registration",
          "type": "json",  // Response Type
          "path": "/api/v1/account/register.json",
          "method": "POST",
          "body": {  // Need to consider body type - form-data, json, ...
            "user[username]": "*",  // Text Field for free input
            "user[password]": "*",
            "user[password_confirmation]": "*"
          }
        },
        {
           "name": "Get Account Info",
           "type": "json",
           "path": "/api/v1/account/profile.json",
           "method": "GET",
           "headers": {  // Merge with or Override global headers config
             "X-EXAMPLE-AUTH-TOKEN": "mock"  // Only one fixed value
           }
        }
      ]
    }, 
    { // Another API Group
      "name": "Articles API",
      "apis": [
        {
          "name": "Get New Article Form",
          "type": "web",  // Render WebView
          "path": "/api/v1/articles/new",
          "method": "GET"
        },
        {
          "name": "List Articles",
          "type": "json",
          "path": "/api/v1/articles.json",
          "method": "GET",
          "params": { // URL Params, i.e. /api/v1/articles.json?page=1&per_page=15
            "page": "\d", // Free input, but Integer only
            "per_page": {
              "value": "\d",
              "optional": true
            }
          }
        }
      ]
    }
  ]
}

@pinglamb and also the body field.

How the original structure distinguish override or merge?

@mystcolor You are right, it is better to be consistent. They are both okay to me. If it matches your UI design, then change it.

My idea is contain all headers in an hash:

{
  "X-EXAMPLE-DEVICE-TYPE" => header_config1,
  "X-EXAMPLE-DEVICE-UUID" => header_config2
}

and you can parse the header arrays in sequence and put the whole config block into the hash.

@mystcolor @yachi Is the revision 44392c good? I keep the consistence and extensibility.
When the header/param name points to a value (string, integer), use directly:

{
  "page": "\d"
}

When the key points to hash, it indicates some more configurations:

{
  "X-EXAMPLE-DEVICE-TYPE": {
    "value": ["iphone", "android"],
    "required": true
  }
}

It is also valid:

{
  "X-EXAMPLE-DEVICE-TYPE": ["iphone", "android"]
}

when we agree to have required equals true by default.

Will it be too much?

looks good to me.

i am still thinking about the additional header section inside each api. the "X-EXAMPLE-AUTH-TOKEN" would likely to be appeared in more than one place. if we needed to change the spec of it, it wouldn't be ideal. maybe we should put extract it out too?

and one minor thing, how about not using "required = true" but "optional = false" by default? to me seems to be a little bit easier to read.

I expect the JSON is generated from a panel, so we can omit the extraction part. Keeping JSON easy to parse by client app is my primary concern.

Changed required to optional

P.S. It is possible to extract common config by borrowing the concept of prototype, for example:

{
  "prototypes": {
    "require_authentication": {
      "headers": {
        "X-EXAMPLE-AUTH-TOKEN": "mock"
      }
    }
  },
  // ......
  {
     "name": "Get Account Info",
     "prototypes": ["required_authentication"]
     // ......
  }
}

great, looks good to kick start!

Great. You can use the raw JSON here to construct the app first. I will write a (partial) Twitter API Spec at the same time so that we have a good target for POC.

@mystcolor Clarification

case single_string
when "*"
  show_text_input(:tip => "Any string")
when "\d"
  show_text_input(:tip => "Number only")
else
  show_fixed_value(single_string)
end