API Design Guide Version 1.0

This PR proposes an API design guide for use at Wikia. It is opinionated about the use of standards for error handling, media types, and HTTP protocol usage. The state of the art in the industry for building APIs has progressed to the point where developers can focus less on attribute naming and protocol semantics and more on solving application specifics. 

With standards like [HAL](http://stateless.co/hal_specification.html) and [JSON-LD+Hydra](http://www.hydra-cg.com/) (among others) all [three layers of API semantics](http://amundsen.com/blog/archives/1138) are closer to being standardized. This means that as a developer you need not spend a lot of time noodling over the JSON payload layout, client-server interactions or API libraries. Use one of the standards mentioned [above](https://github.com/mikekelly/hal_specification/wiki/Libraries) and the above comes (mostly) included.

That said, I'm sure it's also not perfect. It has not (all) been refined by the fire application. It's a work in progress. If you have suggestions or improvements, please open a PR! We also have a [slack channel](https://wikia.slack.com/archives/api-design) for API design. Come and ask questions [there](https://wikia.slack.com/archives/api-design). Feedback is welcome and encouraged.
I changed the wording here to "Start with HAL first." I also added a not about decoupling the domain model from the representation. See 2dd0456.

For posterity, here is my original response in chat:

> I think ideally we would take some from both. For example, I think we want to experiment with microformats in our markup. Search engines and mail clients are using this data provided by content generators to toggle the display of content to users. As a case in point, the NYTimes added microformat data to their recipes and saw search traffic to their recipes increase by ~50% (https://www.scribd.com/doc/224608514/The-Full-New-York-Times-Innovation-Report pp 43). Have you noticed that you can now click on pull requests directly from email rows in gmail (https://github.com/blog/1891-view-issue-pull-request-buttons-for-gmail). Both are using the common vocabulary from schema.org. The latter is using JSON-LD.

> This may not be articulated well in the API Design PR, but I think we need to be nimble in our choice of format/media type. We should build the domain models to get the data and abstract the representation as much as we can.