icoMetrix API Standards

• Guidelines
• Pragmatic REST
• RESTful URLs
• HTTP Verbs
• Responses
• Error handling
• Versions
• Record limits
• Request & Response Examples
• Mock Responses
• JSONP

Guidelines

This document provides guidelines and examples for White House Web APIs, encouraging consistency, maintainability, and best practices across applications. White House APIs aim to balance a truly RESTful API interface with a positive developer experience (DX).

This document borrows heavily from:

• Designing HTTP Interfaces and RESTful Web Services
• API Facade Pattern, by Brian Mulloy, Apigee
• Web API Design, by Brian Mulloy, Apigee
• Fielding's Dissertation on REST

Pragmatic REST

These guidelines aim to support a truly RESTful API. Here are a few exceptions:

• Put the version number of the API in the URL (see examples below). Don’t accept any requests that do not specify a version number.
  • http://example.gov/api/v1/magazines
• By default use JSON

RESTful URLs

General guidelines for RESTful URLs

• A URL identifies a resource.
• URLs should include nouns, not verbs.
• Use plural nouns only for consistency (no singular nouns).
• Use HTTP verbs (GET, POST, PUT, DELETE) to operate on the collections and elements.
• You shouldn’t need to go deeper than resource/identifier/resource.
• Put the version number at the base of your URL, for example http://example.com/api/v1/path/to/resource.
• URL v. header:
  • If it changes the logic you write to handle the response, put it in the URL.
  • If it doesn’t change the logic for each response, like OAuth info, put it in the header.
• Specify optional fields in a comma separated list.
• Formats should be in the form of api/v2/resource/{id}?format=zip

Good URL examples

• List of magazines:
  • GET http://www.example.gov/api/v1/magazines
• Filtering is a query:
  • GET http://www.example.gov/api/v1/magazines?year=2011&sort=desc
  • GET http://www.example.gov/api/v1/magazines?topic=economy&year=2011
• A single magazine in JSON format:
  • GET http://www.example.gov/api/v1/magazines/1234
• All articles in (or belonging to) this magazine:
  • GET http://www.example.gov/api/v1/magazines/1234/articles
• All articles in this magazine in XML format:
  • GET http://example.gov/api/v1/magazines/1234/articles?format=xml
• Specify optional fields in a comma separated list:
  • GET http://www.example.gov/api/v1/magazines/1234.json?fields=title,subtitle,date
• Add a new article to a particular magazine:
  • POST http://example.gov/api/v1/magazines/1234/articles

Bad URL examples

• Non-plural noun:
  • http://www.example.gov/magazine
  • http://www.example.gov/magazine/1234
  • http://www.example.gov/publisher/magazine/1234
• Verb in URL:
  • http://www.example.gov/magazine/1234/create
• Filter outside of query string
  • http://www.example.gov/magazines/2011/desc

HTTP Verbs

HTTP verbs, or methods, should be used in compliance with their definitions under the HTTP/1.1 standard. The action taken on the representation will be contextual to the media type being worked on and its current state. Here's an example of how HTTP verbs map to create, read, update, delete operations in a particular context:

HTTP METHOD	POST	GET	PUT	DELETE
CRUD OP	CREATE	READ	UPDATE	DELETE
/dogs	Create new dogs	List dogs	Bulk update	Delete all dogs
/dogs/1234	Error	Show Bo	If exists, update Bo; If not, error	Delete Bo

(Example from Web API Design, by Brian Mulloy, Apigee.)

Responses

• include identifiers
• include URIs
• No values in keys
• No internal-specific names (e.g. "node" and "taxonomy term")
• Metadata should only contain direct properties of the response set, not properties of the members of the response set

Good examples

No values in keys:

"tags": [
  {"id": "fe264a48-cca7-4760-aaf7-be8402c506bc", "name": "Environment", "uri": "/path/to/resource"},
  {"id": "fe264a48-cca7-4760-aaf7-be8402c507bc", "name": "Water Quality", "uri": "/path/to/resource"}
],

Bad examples

Values in keys:

"tags": [
  {"125": "Environment"},
  {"834": "Water Quality"}
],

Error handling

Error responses should include a common HTTP status code, message for the developer, message for the end-user (when appropriate), internal error code (corresponding to some specific internally determined ID), links where developers can find more info. For example:

{ "id": "fe264a48-cca7-4760-aaf7-be8402c506bc"
  "developer_message" : "Verbose, plain language description of the problem. Provide developers
   suggestions about how to solve their problems here *[NO CONFIDENTIAL INFO]*",
  "user_message" : "This is a message that can be passed along to end-users, if needed.",
  "error_code" : "444444",
  "more_info" : "http://www.example.gov/developer/path/to/help/for/444444",
}

Follow http standards, be specific!

• 200 - OK
• 400 - Bad Request
• 500 - Internal Server Error
• 404 - Not found
• 401 - Unauthorized etc...

Versions

• Never release an API without a version number.
• Versions should be integers, not decimal numbers, prefixed with ‘v’. For example:
  • Good: v1, v2, v3
  • Bad: v-1.1, v1.2, 1.3
• Maintain APIs at least one version back.

Record limits

• If no limit is specified, return results with a default limit.
• To get records 51 through 75 do this:
  • http://example.gov/magazines?limit=25&offset=50
  • offset=50 means, ‘skip the first 50 records’
  • limit=25 means, ‘return a maximum of 25 records’

Information about record limits and total available count should also be included in the response. Example:

{
    "meta_data": {
        "resultset": {
            "count": 227,
            "offset": 25,
            "limit": 25
        }
    },
    "results": []
}

Request & Response Examples

API Resources

• GET /magazines
• GET /magazines/[id]
• POST /magazines/[id]/articles

GET /magazines

Example: http://example.gov/api/v1/magazines

Response body:

{
    "meta_data": {
        "resultset": {
            "count": 123,
            "offset": 0,
            "limit": 10
        }
    },
    "results": [
        {
            "id": "a_guid",
            "type": "magazine",
            "title": "Public Water Systems",
            "tags": [
                {"id": "125", "name": "Environment"},
                {"id": "834", "name": "Water Quality"}
            ],
            "created": "2011-12-19T15:28:46.493Z",
            "uri": "/path/to/resource"
        },
        {
            "id": "a_guid",
            "type": "magazine",
            "title": "Public Schools",
            "tags": [
                {"id": "125", "name": "Elementary"},
                {"id": "834", "name": "Charter Schools"}
            ],
            "created": "2011-12-19T15:28:46.493Z",
            "uri": "/path/to/resource"
        }
        {
            "id": ""a_guid,
            "type": "magazine",
            "title": "Public Schools",
            "tags": [
                {"id": "a_guid, "name": "Pre-school"},
            ],
            "created": "2011-12-19T15:28:46.493Z",
            "uri": "/path/to/resource"
        }
    ]
}

GET /magazines/[id]

Example: http://example.gov/api/v1/magazines/[id]

Response body:

{
    "id": "fe264a48-cca7-4760-aaf7-be8402c506bc",
    "type": "magazine",
    "title": "Public Water Systems",
    "tags": [
        {"id": "fe264a48-cca7-4760-aaf7-be8402c506bc", "name": "Environment"},
        {"id": "other_guid", "name": "Water Quality"}
    ],
    "created": "2011-12-19T15:28:46.493Z",
    "uri": "/path/to/resource"
}

POST /magazines/[id]/articles

Example: Create – POST http://example.gov/api/v1/magazines/[id]/articles

Request body:

[
    {
        "title": "Raising Revenue",
        "author_first_name": "Jane",
        "author_last_name": "Smith",
        "author_email": "jane.smith@example.gov",
        "year": "2012",
        "month": "August",
        "day": "18",
        "text": "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam eget ante ut augue scelerisque ornare. Aliquam tempus rhoncus quam vel luctus. Sed scelerisque fermentum fringilla. Suspendisse tincidunt nisl a metus feugiat vitae vestibulum enim vulputate. Quisque vehicula dictum elit, vitae cursus libero auctor sed. Vestibulum fermentum elementum nunc. Proin aliquam erat in turpis vehicula sit amet tristique lorem blandit. Nam augue est, bibendum et ultrices non, interdum in est. Quisque gravida orci lobortis... "
    }
]

Response: { "meta_data": {...},

results: [
{
    "the posted data",
    "uri": "/path/to/resource"
    "created": "2011-12-19T15:28:46.493Z",
    "id": "a_guid"
}

]

}

Mock Responses

It is suggested that each resource accept a 'mock' parameter on the testing server. Passing this parameter should return a mock data response (bypassing the backend).

Implementing this feature early in development ensures that the API will exhibit consistent behavior, supporting a test driven development methodology.

Note: If the mock parameter is included in a request to the production environment, an error should be raised.