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
            }
          }
        }
      ]
    }
  ]
}

Some questions.

Should the value, and param maps to regex or we'll just keep it simple?
Some entries such as "X-EXAMPLE-DEVICE-UUID" required some hardware info, is it good to have some kind of MAGIC KEYWORD to let the client app automatically fill in?
And I was wondering about those APIs with more then one method such as GET/POST/DELETE, we'll need to make another entries, or we can expand the method to support input of arrays?

@mystcolor

1. Need to find some way indicating the type, ["a", "b", ...] should be a select, "a" should be a fixed value, and I choose to use some regexp symbol for free text input and integer input. Any suggestions?
2. It makes sense, by specifying {"X-EXAMPLE-DEVICE-UUID": "mock"}
3. Multiple methods, seldom I think and the request format (e.g. body) should be quite different for different HTTP methods. I expect a single API entry should be of one method first (for simplicity), see if we should extend it later-on.

@pinglamb @yachi

1. Make sense. array type indicates options, string type indicates regex rules.
   2, 3. Great.

Another question.
maybe it's more clear to do this? This way it looks like the param field. And client side can construct the header section UI that exactly like the data structure. What do you guys think?

 "headers": {
    "required": {
      "X-EXAMPLE-DEVICE-TYPE" : ["iphone", "android"],
      "X-EXAMPLE-DEVICE-UUID" : "mock",
      "X-EXAMPLE-APP-ID" : ["com.example.iphone.app1", "com.example.iphone.app2", "com.example.android.app1"]
    },
    "optional": {
    }
  }

@mystcolor @yachi

The one you suggested is easy for distinguishing "required" and "optional" headers. It depends on how the client uses them. If there are two separate sections for them, it makes sense. If it represents only a flag, the original one should be better. The API Spec JSON is mainly used by mobile client and should aim to simplify the parsing work by mobile codes.

@mystcolor can start implement the client, by using https://raw.github.com/gist/1333945/d46728953711b190b33840c3496731243e436834/api_spec.json.

@mystcolor the headers have the property that inner header config will override the outer one. Do you think the new structure makes this feature difficult to achieve?

@pinglamb The original one looks longer but more flexible, the second one looks shorter and can directly transform to my imagined UI with that data structure.

The flexibility we know that is can handle more kinds of configurations additional to name, value, required field.
Is the param and header section in same situation?

@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