Back in 2006, Jeff Lindsayproposed a different way of consuming Web resources that would eliminate the need for constantly polling APIs for changes. This new pattern was called webhooks and has since been adopted by companies such as GitHub and Google.
The main advantage of the webhooks pattern is that your application doesn’t have to make periodic calls to APIs while it’s waiting for changes. Instead, APIs will call your application on a specific endpoint informing that something interesting has happened. What’s missing is a way to programmatically tell APIs that you’re interested in receiving calls and registering endpoints.
The first implementable draft of HTTP/2.0 was released on July 8th by the HTTPbis working group of the IETF. The 2.0 version of HTTP is based on the SPDY protocol developed by Google — in fact, the initial draft was a copy of the SPDY specification as a base for diffs.
Photo by Jeffrey Beall
HTTP/2.0 is intended as an alternative to HTTP/1.1, rather than deprecating the old version. There is good reason for this: The new version feels similar to the old, but there are important differences designed to enable more efficient network communication.
So many negatives have been brought forth in the past on OAuth 2. Where there might be continuing points of contention, there is one area which seems to be clear: the “Resource Owner Password Credentials Grant” (OAuth 2 Spec, section 4.3) pattern as defined in the OAuth 2 spec is fundamentally superior to HTTP Basic authentication.
When developing an API, one of the first critical decisions every developer must face is that of Content Type. In this day and age most APIs return one or both of JSON or XML.
photo by Sean Svadilfari
Some APIs get away with one, and that’s fine, but to improve the UX of your API, you should allow the requestor to determine what data type is best for them. If you’ve read the post on API Content Negotiation, you’ll know the best way to approach content negotiation is to follow the standards.
While Maslow’s goal was to understand and explain the priorities of human needs, from breathing and feeding to self-esteem and morality, the API hierarchy of needs explains different characteristics that make an API usable.