Wouldn't It Be Great If All APIs Followed RESTful Principles?
APIs and connecting web applications together is going to be the next challenge of the evolution of the web. The next decade should see easier-to-implement, yet more secure methods for connecting the various web applications that we use.
We're already seeing this in simple ways: RSS, Atom Publishing, Web Hooks. But these are generally insecure. They have been built/conceived with a set of specific goals in mind and then adapted – shoe-horned – to fit a variety of other purposes.
We are making progress: APIs have flooded the web. Mashups threaten to implode the universe in their brilliance. But there are still hurdles. There are still no standards.
REST is just a set of principles (for many things, not just web app APIs). HTTP-REST for Web Service APIs is no definition of a standard method for implementation. It doesn't even begin to address the need for documenting or versioning APIs.
SOAP is better, but this is so wrapped up in corporate boggling and debate that real developers are reluctant to use it (as evidenced by the fact that 68% of APIs are built on RESTful principles vs 19% on SOAP) or simply want a more open standard.
Even if all web service APIs were RESTful, we still need a better method of standardisation and documentation (and implementation could be a lot easier with some other common features set down in stone).
What we need isn't another working group to start thinking about how to solve these problems, but rather, someone to stick their neck out and do something to tackle these challenges.
We are at a turning point. The languages and processes are in place. The standards that need to be ratified have been. The scalability challenges are fading away. The core building blocks of something brilliant are there.
This is why I am building reactor. It's aim isn't to create a formal standard that all others must obey, but rather to encapsulate existing and future systems, boil them down to their basic standards and provide a single, simple point of entry into every API out there.
My vision is to make it easier for API implementers (provider developers) to standardise and document their APIs and easier for integrators (consumer developers) to consume those APIs in a standard way.
Does this sound like something you'd be interested in getting involved in? If "HELL YEAH!!" is your answer, then sign up for the mailing list.
We're already seeing this in simple ways: RSS, Atom Publishing, Web Hooks. But these are generally insecure. They have been built/conceived with a set of specific goals in mind and then adapted – shoe-horned – to fit a variety of other purposes.
We are making progress: APIs have flooded the web. Mashups threaten to implode the universe in their brilliance. But there are still hurdles. There are still no standards.
REST is just a set of principles (for many things, not just web app APIs). HTTP-REST for Web Service APIs is no definition of a standard method for implementation. It doesn't even begin to address the need for documenting or versioning APIs.
SOAP is better, but this is so wrapped up in corporate boggling and debate that real developers are reluctant to use it (as evidenced by the fact that 68% of APIs are built on RESTful principles vs 19% on SOAP) or simply want a more open standard.
Even if all web service APIs were RESTful, we still need a better method of standardisation and documentation (and implementation could be a lot easier with some other common features set down in stone).
What we need isn't another working group to start thinking about how to solve these problems, but rather, someone to stick their neck out and do something to tackle these challenges.
We are at a turning point. The languages and processes are in place. The standards that need to be ratified have been. The scalability challenges are fading away. The core building blocks of something brilliant are there.
This is why I am building reactor. It's aim isn't to create a formal standard that all others must obey, but rather to encapsulate existing and future systems, boil them down to their basic standards and provide a single, simple point of entry into every API out there.
My vision is to make it easier for API implementers (provider developers) to standardise and document their APIs and easier for integrators (consumer developers) to consume those APIs in a standard way.
"One API to rule them all"
Does this sound like something you'd be interested in getting involved in? If "HELL YEAH!!" is your answer, then sign up for the mailing list.
Comments