-
-
Save pinglamb/1333945 to your computer and use it in GitHub Desktop.
{ | |
"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 | |
} | |
} | |
} | |
] | |
} | |
] | |
} |
@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
@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.