Friday, January 23, 2009

REST and WebSphere in 2009 Trends and Directions

Jerry Cuomo recently mentioned in an InfoQ article the WebSphere trends and directions for 2009

One of those topics was a comment on the support the WebSphere was doing in the area of REST (and the need for a common REST API), and how we are working to allow our own products as well as customer applications to be developed quicker and easier (promoting an ability to react faster and be more Agile).

Anne Manes made a comment about why we need a REST API - isn't HTTP GET,PUT,POST, DELETE enough?

I've provided an update with respect to where I think Jerry was headed via his comments (and what we are doing in WebSphere to provide value to customers)..

However - I find it interesting that folks think that REST is so much easier that you don't need any more information that 4 interfaces. You still need to know what the resources identifiers are and what is the resource state actually represents in order to use them (irrespective of the actual encoding/formatting of that data). That need isn't any different than any other distributed communication mechanisms that I've worked on in the past. I've worked w/SNA, TCP/IP, DSOM (Distributed System Object Model), CORBA/IIOP, Web Services, and now REST - as I'm focusing on REST within WebSphere. Irrespective of the technologies around (and I've seen all the comments about problems w/the technologies, tight coupling between technologies, lack of interoperability, etc...) - at the end-of-the day - you have a "client" making a request for information to some "service/resource" and it needs to understand the format of that data to accurately process the data. If you change the format, you potentially break the client. In a web-presentation world and HTML, the data can change the data, but our human minds can easily understood if the data format changes. For example, recently changed their web site around - however, I can still manage to deal w/it - since human minds can easily comprehend it. However - I know that if I wrote a script looking for the scores of yesterday's games (thereby automating it)- that it would fail since the location/context of that information is now in a different spot and presented differently.

In the end - I think we need to take our focus off the technologies themselves, and place the focus more on the value obtained in using the technologies to achieve a business goal. Defining patterns and best practices to use technologies are as critical to making our customers succeed as the technology itself. Anti-patterns are also valuable as the prevent customers from following practices known to be error prone. WebSphere focuses on producing middleware so that it can provide to customers an ability to expose data, services, whatever is needed for customers so that they can more easily provide value to their customers. I think all Jerry was alluding to is that by trying to be consistent with how we expose data/interfaces amongst our products, we can use those as best practices and patterns for others to do the same. That is what we are doing in WebSphere. As we can, we will publish best practices and use cases for using our technologies. In addition, in cases that we know we can do better - we are learning from those efforts and will be listing those as anti-patterns. Every time I have a discussion w/our services organization that use our technologies - that's the first question they ask - please give me reference patterns and anti-patterns.

Those who cannot remember the past are condemned to repeat it.


Anonymous said...
This comment has been removed by a blog administrator.