Thursday, January 22, 2009

"Common REST API"?

Jerry Cuomo published an article on InfoQ yesterday: 2009 Trends and Directions for WebSphere. In it he discusses his Top 10 list of R&D projects for the WebSphere team in 2009. One of the items on the list is REST (which for some reason he combines with Agile). He says:

Restful / Agile – In 2008 we made solid progress in REST enabling our WebSphere portfolio. I’m quite proud of the team for aggressively responding to the call; including the REST enabling in CICS, WebSphere MQ, WAS, WSRR, Commerce, Portal, Process Server, and the list goes on. We have more work to do in 2009. Specifically, with all this REST work, a Common REST API is needed across these products. Complementing our work on REST is our work on Agile programming – specifically the dynamic scripting capability (PHP and Groovy) that is the hallmark of our WebSphere sMash product...

I must say I'm flummoxed by his assertion that IBM needs to develop a "common REST API" across the WebSphere product family. I always thought that one of the fundamental constraints in REST is "uniform API". Wouldn't the common API be GET, PUT, POST, and DELETE?

Maybe I should go back and read the REST dissertation again. I must be missing something.

I'm also not sure I understand why Jerry appears to be linking Agile methodologies with dynamic languages. Again, I think I must be missing something.


oisin said...

I would say they are looking for a nice tag for this - and that expression can be converted to the initialism CRESTA. Puns ensue.

I can see an application of the term. If you have a number of products that are offering REST access, it might be attractive to construct a set of conventions common to all those products. For example - a convention for appending a result paging value on the resource URL as a query or parameter. This is something that doesn't really affect the state of the target resource, but instead indicates a delivery option (which may be implemented by an intermediary).

So - for common REST API, read "consistent conventions in place in products that support RESTful interaction".

Greg Truty said...

API means different things to different people. Quoting from Wikipedia[1] (which takes it's quote from ComputerWorld[2]):
An application programming interface (API) is a set of routines, data structures, object classes and/or protocols provided by libraries and/or operating system services in order to support the building of applications.

The API is a relatively abstract term - but can include specifics of the necessary information to help build application. While the HTTP protocol and exposing of resources is one usage pattern of an API - one needs more information than just HTTP protocols to build an application. Information about the resources available (i.e. the URLs exposed), the capabilities that are supported on that resource (GET, UPDATE, POST, etc...), as well as what information is available in the request (URI parameters, body information, etc...) are all important. As our products are enhanced to both expose APIs for users to build their own REST-based services, as well as resources available within the products themselves - we are finding that there are patterns emerging for how one defines the resources that are available as well as documenting the various patterns and practices that others use in exposing resources. For example, patterns for handling paging of large numbers of resources, querying other resources emerge and having a consistent set of APIs available amongst the given products allows technologies to be more easily consumed (this is mentioned by the prior comment). The DOJO toolkit (which IBM supports in the WebSphere Feature Pack for Web 2.0 and WebSphere sMash) has the capability to display a grid of data retrieved from a data store. Hooking that data store up to a back end REST-based resource (and following a consistent pattern) allows users to successfully use that as a template for creating a returning a collection of resources that can be scrolled through. Handling and exposing of querying of data is another such example.

In addition, each product is introducing their own REST-based resources where it makes sense. IBM prides itself on providing consistency, integration, and value in providing solutions to customers with combining numerous products together. Therefore, providing consistent documentation, and capabilities of these technologies and showing it's interrelationship is one such example. For example, our WebSphere sMash provides a mashup development environment and provides the ability to create REST-based resources. It blends well with our Lotus Mashup Center which allows these resources to be assembled and aggregated. It, in turn, also blends well with the IBM InfoSphere MashupHub providing a mechanism for sharing REST-based resources for building new applications.

As for Agile and linking Agile methodology with dynamic languages, I was specifically talking about the ability to quickly expose and build new situational applications to provide business value to customers using technology which is flexible and good enough to satisfy short-term customer needs. Much of our focus on introducing REST-based APIs (and to a great extent) SOA services in general - is to make both services and data that we provide to customers available to be consumed in order to help them make better decisions. I've already spoken about creating new applications quickly with WebSphere sMash and Lotus MashupCenter. However - we also extend the capabilities to our higher level business value products. For example, WebSphere Process Server has REST-enabling key business performance indicators and allows them to be viewed on a our WebSphere Business Monitor dashboard. This allows critical real-time information to be exposed to business analysts so that they can make valuable decisions on how to change and affect their business. Our focus is about providing flexibility for our customers so that they can be agile and respond to the ever changing world in front of them.


Greg Truty
WebSphere REST and Web Services Architect

dizz said...

Perhaps what the guys over at IBM need is a common schema (as opposed to a common API), hence common understanding of resources, between all their applications? Having a common understanding of the resources will as a result of REST expose a "common API" (get, put, delete, post, options, head). If the guys still think in terms of API with respect to REST then that most likely is the crux of their problem.

Gerry G said...

I'm assuming the "common API" is either a message vocabulary or messaging API layered on REST. Web services that use REST still need to be designed, and shared design principles across products make the services much easier to understand and consume. I'm also assuming here that people are making REST more complex (ie, SOAP-like and/or document-centric) than it needs to be?

Note that he said "Websphere line". Something I'm learning is that IBM isn't good about sharing things across product lines (Websphere, Infosphere, Rational, etc.) and seems to have a co-opetition model internally. Common principles and designs across product lines appear to be unlikely at this point.

As for the other part, "Agile Programming" made sense to me, and I wouldn't personally translate that phrase to mean Agile methodology. He may be stretching things a bit and not be very precise in what he probably means, but I got what he meant.

abby brock said...

I am so glad this internet thing works and your article really helped me. Thanks for this.

movers in virginia