- API Management
- Contact Us
Off to PHP|TEK, and favoring protocols over APIs
Scanning through my news feeds before getting ready for php|tek this year, I found this article about favoring protocols over APIs and it raises some good points about API design and interoperability. The main focus of the article is that an API is really an agreed-upon combination of a protocol and an endpoint, and that if more standardized protocols are developed and used, changing endpoints becomes trivial.
As an example, take XMPP. There are thousands of messaging services that are built on top of the XMPP protocol, from well-known public services like Google Talk to private internal chat services run on company intranets. Because the protocol is standardized, there are also many different clients that support the protocol. Because the services all speak XMPP, the clients can interact with any of those services by changing their endpoints.
All of the players in that interaction gain value by using the protocol. The clients get a bigger audience since they can connect to more services, and the endpoint providers get to rely on standard libraries for building and documenting their service, so there service code can be more DRY. It's not just simple messaging protocols that can benefit from this idea.
Any industry or business case has the potential for a standard protocol. For example, the OpenTravel spec allows for transfer of flight information, hotel reservations, car rentals, and several other pieces of travel-related information in a standardized way. There are many other standard protocols too, for example weather data or news. The more companies that adopt a specification, the less friction there is transferring data in that industry.
Imagine how much easier it would be to build a news aggregator app if you could connect to 20+ news outlets and parse all of the responses exactly the same way. If you're building an API, consider implementing a standardized protocol if one already exists in your business space. If you're consuming an API that is not built upon a standard protocol, see if the API provider is willing to work with an existing standard, or propose their own.
If you'd like to talk about this or other API geekery, come see us at php|tek in Chicago this week. We'll be mingling around in different sessions or hanging out at the Mashery booth. Look for us at the unconference too!