nemetral.net | Insightful posts on design and code
Already the seventh post of series "The pursuit of APIness", and it is now time to conclude by outlining another strategic issue substantially bound to APIs: local expertises. As a matter of fact, since the very goal of an API is to cross the line of existing web property (i.e. a website, a database) and open monitored accesses to data, releasing an API can make other websites orbitting in nearby niches use your API, i.e. use your data, i.e. transform your data into the local reference.
The first five posts of series "The Pursuit of APIness" went through technical examples of how APIs actually work, from an illustration of how to hack a web form with a PHP script to how to design and program an API using custom XML, or following the REST principles, or using XML-RPC or SOAP. It is now time to wrap up everything we've learnt about web APIs and to understand why they're so strategic.
XML-RPC is damn easy to use and many projects still rely on it. But for a few years a new protocol has emerged: SOAP. SOAP is traditionally considered as an evolution of XML-RPC. Selected by Google for its famous Search API (now deprecated), the SOAP protocol is usually considered as more complex than plain XML-RPC messaging. In fact, if you understood XML-RPC, then you should have no difficulty to understand SOAP as well, the latter being mainly an abstraction of XML-RPC.
Last week we reviewed the principles behind a RESTful architecture. This week, as part 4 of this series dedicated to web APIs, we will focus on XML-RPC which, contrary to REST, is not a set of general principles but a substantial specification on how to format XML messages carried over HTTP.
In part 2, we saw how could be designed an XML-based API structure for fictitious website community.com allowing 3rd party developers to get access to members of a given age and living in a given city. The problem was: is it really a good idea to let every website or webapp design its own fancy API? It is now time to introduce the 3 main standard API structures: REST, XML-RPC and SOAP.
Last week we looked at web forms and we observed what was happening under the hood in terms of requests and data transferred; as an example, we tried to emulate a specific web form through a PHP script which sent a request to the web server and parsed the result to extract relevant information. The conclusion was: it's possible, but it's not clean. This week we'll see how transparent automation can be.
Say you need to upload a set of 100 pictures on Flickr everyday. Not so difficult: you login to your Flickr account and start to manually upload the pictures. After a few days though, you start to feel a bit weird about having to spend all this time to manually upload files at an era where computers, after all, are supposed to replace us for repetitive tasks. Say your daily sets of 100 files are prepared in advance: wouldn't it be great if your computer could upload them to Flickr on its own?
Nemetral is a freelance webdeveloper with 8+ years experience in the industry. On nemetral.net you will find insightful posts on design and code, tackling various topics related to webdevelopment from a highly educational perspective.
The very best of nemetral.net, as selected by readers.
Integrating design and code.
Exclusive articles written by nemetral, published elsewhere on the web.
