Browse Prior Art Database

Creating Hybrid REST Service URIs on Demand

IP.com Disclosure Number: IPCOM000180251D
Original Publication Date: 2009-Mar-05
Included in the Prior Art Database: 2009-Mar-05
Document File: 4 page(s) / 36K

Publishing Venue

IBM

Abstract

Problem: The users of a REST service often have to make several REST calls to a REST data service to get to the data they need. Generally, a REST client would make several Http requests to traverse the entities it is interested in. Even with the best design, not all usage scenarios can be covered by the REST URI server. Some mashup services do provide server side mashups as the usage scenarios and domain are well known. But such services do not provide a way for the clients to compose their own server side mashup services/URIs. It is not feasible to provide server side mashups when, either a large number of entities are involved or when the usage scenarios are as varied as the clients. This results in several round trips to the REST service causing both client and server to perform additional work resulting in avoidable network traffic and potential performance degradation. While the server side code can be modified to support URI aggregation to provide a server side mashup, this can't be done without going through a design, code, test cycle. Even then, a new client might need a different mashup which can't be created dynamically. In a nutshell, today, clients can't create server side mashups on demand without any changes to the server code. Known solutions: 1. Client side mashups. This approach doesn't reduce the Http traffic. Multiple http requests and processing result in performance degradation. 2. Server side mashups. Neither created nor controlled by clients. Limited and fixed set of mashups. Suffer from recoding/implementation/redeployment issues.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 45% of the total text.

Page 1 of 4

Creating Hybrid REST Service URIs on Demand

Problem: The users of a Representational state transfer (REST) service often have to make several REST calls to a REST data service to get to the data they need. Generally, a REST client would make several Hypertext Transfer Protocol (HTTP) requests to traverse the entities it is interested in. Even with the best design, not all usage scenarios can be covered by the REST Uniform Resource Identifier (URI) server. Some mashup services do provide server side mashups as the usage scenarios and domain are well known. But such services do not provide a way for the clients to compose their own server side mashup services/URIs.

It is not feasible to provide server side mashups when, either a large number of entities are involved or when the usage scenarios are as varied as the clients. This results in several round trips to the REST service causing both client and server to perform additional work resulting in avoidable network traffic and potential performance degradation. While the server side code can be modified to support URI aggregation to provide a server side mashup, this can't be done without going through a design, code, test cycle. Even then, a new client might need a different mashup which can't be created dynamically. In a nutshell, today, clients can't create server side mashups on demand without any changes to the server code.

Known solutions:
1. Client side mashups. This approach doesn't reduce the Http traffic. Multiple http requests and processing result in performance degradation.
2. Server side mashups. Neither created nor controlled by clients. Limited and fixed set of mashups. Suffer from recoding/implementation/redeployment issues.

Proposed Solution: If we allowed the clients to 'compose' a server side URI mashup on the fly, the server could invoke the data fetch in a non Http way and aggregate the data needed in a much more efficient way. The client would need to make only one Http request and get the data it needs. This would obviously be much faster. We propose a framework to allow trusted REST URI clients to compose server side mashups on the fly.

A client would send a compose message which the server would process and generate a new URI. Typically, this would be an Http POST message with the composition of the hybrid REST URI. The server would return a URI pattern and an ID in response which the client can later use to invoke the new hybrid URI.

Using this approach, the server need not do data aggregation unless it is needed. It is highly flexible and customizable to the needs of individual client. The server's REST URI implementation can initially be very basic,

just serving up base entities with the bar

minimum variants of the URIs. The runtime implementation can leverage reuse of several such hybrid URI compositions if they already exist.

This method will also allow the users of mashup builders to build UIs using the entities...