Ealier this year Cap Gemini's Steve Jones asked whether or not REST was successful in the enterprise? Steve believes that REST in the enterprise isn't just dead, it was still born:
SOAP isn't undead, its very much living in the enterprise and indeed being the only real viable approach when integrating package solutions from a number of vendors (a massive piece of enterprise IT). REST however barely registers, less than 2500 APIs after all these years of development? Pathetic.
REST for the enterprise isn't undead... it’s been still-born for over five years.
These articles generated a lot of discussion with the usual extremes of opinion where REST and SOAP are concerned, even now many years after those conversations began. The only conclusion that can be drawn is that there are areas where SOAP works well and then there are areas where REST is to be preferred. But defining precisely what those areas (scenarios) are will often cause yet more debate (argument?) Well now Steve has something else to add to the debate and this time it's a discussion about whether a renaming of REST can help the current situation, using something that has recently happened at Facebook to illustrate his point: they have deprecated their REST API in favour of what they are calling a Graph API, as Douglas Purdy from Facebook mentions:
Note: Deprecating the REST API does not mean we are removing it, but we are actively encouraging all developers to use the Graph API for any new apps and to move existing apps to use it, as well. Moving forward, all new features will only be available in the Graph API and the level of support will be higher on a non-deprecated API.
Now as Steve points out correctly, it would be wrong of him and others to use this example as proof of that REST doesn't work for the Web because it clearly does: despite all of the REST versus SOAP arguments, probably the only thing that almost everyone agrees on is that REST works for the Web! Furthermore, when examining the approach that Facebook have taken, their Graph API appears very RESTful. Therefore, Steve believes that rather than technical issues, what Facebook actually suffered from with REST was a naming convention.
The folks at Facebook called the first API the 'REST API' which meant when they felt that there were problems with it they then had two options
- Have a new API called REST API 2.0
- Create a new name
Steve believes that the term 'Graph API' is actually far more informative than REST, because it describes that REST is good at: the traversal of complex, inter-related, networks of information. He also believes that there may be some benefit to distancing the technological approach from the often "religious" fervour that can be found associated with REST (and SOAP). He concludes with:
'Graph based reporting' is something I could see catching on much better than 'REST'. So have Facebook actually hit on a term that will help drive RESTs adoption? Probably not in the system to system integration space, but possibly in the end-user information aggregation/reporting space.
It remains to be seen whether a different name can actually make a difference, or whether the Graph API is really RESTful and if it is, whether it will remain so.