As mentioned in previous blog, REST is a style than a systematic way defining distributed interfaces. Given how it’s used today, there is a big gap between how it’s used and sophisticated software system development.
The gap between REST and OO
We all know OOD/OOP dominate modern application software development today. The key value of OO is higher level of modularity so that developers can think at the object level rather than the function and data level in the procedural programming. It’s also much more natural to map the application domain to the programming domain while designing software than before. These benefits result in higher productivity of a development team, which make OO almost a default in application development today. Note that we only discuss application development, not system software like operating system. In the foreseeable future, procedural programming is still dominant there.
What is the idea?
Now let us see how we can fill the gap of REST and OOP. One of the key concepts in REST is resource, which can be created, read, updated, and deleted (CRUD, sounds like SQL?). These CRUD operations are then mapped to different HTTP methods like PUT, GET, POST, and DELETE correspondingly. All sounds good but a little complexity un-necessarily at the protocol level.
If we think of the different resources as objects, then the gap is filled in some way. Each resource type is defined as a class which has four methods, which correspond to CRUD. The object model built in this way is quite straight forward.
The problem is not all the object model fitting into this CRUD style. But people would like to use REST anyway given its popularity. Even complicated is the association of these resources, which can be a little difficult to define.
All the discussion and thinking are in one direction – how to create OO model from an existing REST? How about the other way – how to create a REST API that is OO friendly or OO ready? You will find the problem becomes easier all the sudden.
How it works?
The process has to start from an OO model. Assume you already have one. It has a type definition among others:
class Foo
{
Attribute A1;
Attribute A2;
Method M1();
Method M2();
}
Now you can easily design a URL that fits REST style:
GET http://<target_system_base_url>/obj=<obj_id>&attr=A1
This gets you a XML message of attribute A1.
POST http://<target_system_base_url>/obj=<obj_id>&method=M2
This activates the method M2 at the server side with the parameters in POST body which are not shown here.
Here you don’t need other methods other than GET and POST, or simply POST. Keeping GET method has a little benefit that you can use any browser to view the content of the resource. When using POST method and you have extra parameters to pass in, you have to include them inside the body of request message.
The obj_id should have two parts: the type name and the ID. Putting it in SQL way, they are the table name and the primary key value. Alternatively, you can flatten it out to have only one unique value for every object despite its type. In so doing, you have to have a look up table at server side to reverse the single value to type. Both work fine, but I think the former way works better.
What is more?
With the above object model to URL mapping, a systematic way is formed to handle the problem. It’s not fully done yet. It still lacks details on passing back and forth the attribute, parameter and return values. Fortunately it’s not a big deal. XML serialization can help here as it does for the SOAP with WSDL. Of course you don’t need all the WSDL schema here but the data type definition and the message definition. The reason why later is needed is to handle multiple parameters in a method, where you have to define the sequence and packaging. This part is however optional if we all agree to a convention for example, first parameter’s serialized XML message comes first with its parameter name as its enclosing tag.
Benefits
With OO REST, you can focus on the object model design instead of URL syntax, which is in my opinion really wrong focus. For any design, the key element is the concept model. In software API design, the concept model is the object model. Focusing on the object model gets you better, not sure though, chance for easy to use API design.
Secondly, OO REST is friendly for code generation. Once you have a good object model, you can generate code and facilitate the underlying plumbing code for both the server and client. In today’s REST, you have to pretty much code everything manually. Unfortunately, we don’t have tools to support this but it’s not a big deal even if you do it by yourself. Ideally we should have some sort of standard tools for this.
Last, but not the least, OO REST is still REST even though not in the conventional way. If you like to code at REST level, you can easily guess the URL without looking up the spec for exact URL pattern as you have to do today. So it’s a relief for everyone.
Author: Steve Jin is the author of VMware VI and vSphere SDK (Prentice Hall), creator of VMware vSphere Java API. For future articles, please subscribe to RSS or Email, and follow on Twitter.
Comments (3) 
