Part 1: The Web
In the beginning -- way back in the beginning -- the web was all about open access. Tim Berners-Lee and his colleagues focused on making information available, not on protecting it from unauthorized users.
But as time went on, and as Al Gore took the initiative in liberating the government-run Internet backbone for commercial use (really), the Web became about "e-commerce," and e-commerce required security. SSL matured to ensure that sensitive traffic was encrypted all the way from the client to the server and back, and various schemes emerged to allow user authentication.
Twitter unleashed a firestorm this week by announcing a change to their API policy for apps that enable users to read and write tweets.
Their announcement is not a big deal – it effectively says, “simple clients to send and receive tweets are core. Don’t go there. And don't copy our experience.”
This is actually the right type of communication from a platform company. You want them to say “There are risks for you here as we’re building stuff. We would like to see further innovation in this other place over here.”
This is always the case with platforms...
Last week I wrote that if you're API doesn't support JSON and JSONP - you're doing it wrong. I don't think that's terribly controversial.
But is JSON (and JSONP) perfect for everything you need to support with your API? Is XML dead?
Reading the Universal Principles of Design and caring passionately about APIs got us thinking about how to apply those principles to API design. In a four part series, we'll cover 13 design principles from the book:
- Development Cycle
- Flexibility-Usability Tradeoff
- Hick’s Law
- 80/20 Rule
- Inverted Pyramid
- Advance Organizer
- Self Similarity
- Aesthetic-Usability Effect
This is an...