Well, we've always had a couple of API's, which were then bundled up into different coding languages called SDK's to make it easy for the developer to select the SDK depending on the language they used and then go off and implement the API within a few minutes - as long as everything else had been done.
The problem is that there are a huge number of languages out there, and that sometime meant that the developer did have to recreate the wheel to a certain extent, whereas that's not necessarily so with the ReST API.
For me the ReST API has two key advantages over the old Form POST and SOAP and ActiveX API's - it's a lot more lightweight, meaning that the servers and PC's don't have to process as many lines of code in order to complete the task at hand, which is always a good step, and secondly it support a wider range of coding environments.
Additional advantages beyond that is I think it's a lot simpler to use, and for a lot of new applications ReST seems to be the path they are going down anyway which means going forward when old application get redeveloped and new ones are born, then ReST is a go way to go.
Even beyond that, the benefits of the ReST API allow for a much wider range of functions to be added at will too, without a lot of labour required and for the customer I guess that equates to functions and features coming out a lot quicker than the otherwise would do.
So why is everyone looking at ReST anyway?
Well according to wikipedia, the goals of ReST are;
- "Scalability of component interactions
- Generality of interfaces
- Independent deployment of components
- Intermediary components to reduce latency, enforce security and encapsulate legacy systems"
Pretty good reasons huh?
I think so.
Cheers,
C