Archive for the ‘REST’ Category

Web + API + CORS = Like

June 22, 2012

In my previous post around API driven web application architectures I delved into the need for every web application to have a corresponding API. There is shift in trends around scalable web application development.

Enterprises need “micro applications”  not “monolithic  applications”.

Take a look at Mary Meeker’s latest Internet trends which talks about mobile devices way surpassing PC based access as we step into the latter half of the decade.

Mobile apps need APIs, not UIs. Devices need APIs not UIs.

If you are building an enterprise application, build your API first not your UI. Of couse UI and User experience is really important and you will continue to court users over the web access from PC devices/mobile browsers.

Which comes to the real heart of this post. If your web application and API applications are two (or more ) applications, how do they talk to each other. Let’s look cover the basics before we review our options.

The Protocol: REST…REST…REST


This also implies that you should be using JSON for your data exchange and HTTP/HTTPS as your underlying transport mechanism. If your are thinking of XM-Hell, then think again.

The Client: HTML5, Javascript, CSS3

HTML5, CSS3, Ajax, Javascript are starting to make a huge comeback. Thanks to the Google(s),Facebook(s),Twitter(s), LinkedIn(s) of the world to popularize the power of client side scripting and the trend that is also know as “single page web apps”.
Note: If you have not read LinkedIn’s tech blog about how they build their iPad app, I would strongly recommend you do.

The options:

Ideally you should be able to do a Ajax request (GET, POST, DELETE etc.) over to your API app and it should work. Browsers have prevented this with the “Same origin policy” for JavaScript. This policy is a really good thing as it helps web applications be less prone security hacks that allow arbitrary scripts to be executed as the user. Given this policy, there are three options to get your web application to talk to your API:
  1. Server side Proxy
  2. JSONP
  3. Cross Origin Resource Sharing (CORS)
Server side Proxy 
This is the most obvious choice and probably what most developers will start with. Here’s how the sequence of events play out with this option:
This is certainly a very good option and is the chosen road for most applications especially when the web app needs to interact with a 3rd party API that the app does not control.  However proxying every request, has performance tradeoffs as well the need to keep the server side code up-to-date with the API versions. In the world of JSON/Ajax type web apps, the server side component is not adding too much value.
Short for JSON with Padding, allows you to inject <script> elements at runtime and invoke a server side URL that returns the JSON data wrapped in a Javascript function. Read more about it here. The flow of events for JSONP is below:
For e.g. say your API end point is, the sequence of events would be:
  1. Your Javascript library (JQuery etc.) would create a new <script> DOM element with “src” attribute set to
  2. The API will receive a HTTP GET request, process the request and generate the JSON response
  3. Once the response is generated, it will wrap the JSON response around the Javascript function name and return the response setting the Content-Type header value to application/javascript
    The response would be something like this:

    javascriptFn({'responseStr':'Response Value'});

  4. The Browser receives the response and because the content type is set to JavaScript, it will attempt to call the function called javascriptFn passing in the JSON response. The function can now update the DOM/do any processing with the data as it deems fit.
The major downside is because this is all happening over HTTP(S) GET you cannot really pass in HTTP headers (e.g. Auth information) which essentially makes this a very un-secure option. This is a major reason why most IT/ Enterprises shun this approach. JSONP is certainly an option for any public web services that does not give away any user specific secret/authentication credentials.
Cross Origin Resource Sharing
Cross Origin Resource Sharing (CORS) is a more recent technique that overcomes the downsides of JSONP and provide a more “secure” way for your applications to talk to each other. It is currently a “draft” spec by W3C ( However most modern web browsers have added support for CORS already.  For a good list of support browsers, go to
Implementing CORS on a server is as simple as sending additional HTTP headers, for example:


There are additional headers that can be sent as part of the response. Below are some additional headers:


On the client side, you call your API using the standard Ajax / XMLHttpRequest method. For e.g., if you were using JQuery (you should if you are not !!!). The code would look something like this:

function callApi(){
$.get( '',
{requestParam: 'Parametervalue'},
doSomething(responseJson); console.log(d);

The browser when making this Ajax request sends the following header as part of the request:

Origin: http://foo.example

In addition, the client(browser) can send an additional Access-Control-Request-Method and Access-Control-Request-Headers header values for fine grained control on the HTTP Method that is being used to make the request.

The server will receive this header and determine if the Access-Control-Allow-Origin should be sent back with the corresponding value.


Java on the Cloud in 5 minutes

March 16, 2012

Getting started with Java apps on the cloud just got “super easy”. It takes 5 minutes. Check it out at

“So easy even a Ruby Developer can do it”

Heroku for Java Developers

Back when I started doing active web development with Java using Struts, Spring, Spring MVC, i had to :

  • Create a Eclipse project
  • Declare my dependencies (Spring templates when available)
  • Create a local database
  • Build my persistence logic using JPA/Hibernate
  • Build and Test locally

All this and yet not runing on the cloud. If I wanted to share my app with a colleague, I really cannot unless I send them a Zip file of my project or give them my IP address.

Not an easy task !!! Now with the new and improved page on Heroku for Java developers, I can get a Spring MVC template app created and deployed to the cloud and available all in 5 minutes.

Now you can share your app with your colleagues, friends or bosses and focus on what you do best, “building the next big cloud service”.

Heroku also provides 4 getting started templates which covers most “customer engagement” applications that you will be build. It has templates for:

  • Spring MVC-Hibernate on Tomcat
  • Basic Hello World with Embedded Jetty
  • Play! app  (if you want to stay ahead of the next big thing in Java you should check out Play!)
  • RESTful API using JAX-RS and Jersey

Where’s my API?

January 30, 2012

In todays world where startups are growing by the thousands every hour, the way engineers, enterpreneurs, CIOs, CTOs, Architects look at products has completely changed. Everything starts with the web experience or Application UI (App-UI) as product designers and engineers call it.

In parallel another transformation has been occurring in Enterprise application space (now called Enterprise 2.0). First it was embracing “Cloud computing” in the enterprise and second distributed applications on the cloud and how these applications can talk to each other. I was following “Services Oriented Architecture” for a while and it started to get more convoluted about standards etc. A simple example of old school enterprise application is the class SOAP vs. REST based architectures. REST is starting to win the game as we are starting to see more applications embracing RESTful architectures.

REST introduced another amazing innovation in the application design arena. The fundamental fact that every application needs to expose an API. Thanks partly to the “social media” proliferation and facebook, twitter and google exposing a rich set of APIs that can allow 3rd party developers to build their own App UI on top of their APIs. Seesmic is a great example of such an application that leverages APIs from multiple social media sites and aggregates it in 1 single place.

Which brings me to the point of this post, the next time you start to build an app, think of how other developers can extend it using an API and not just how “users” will use the app.  Start thinking of Applications as a composition of App-UI + API. Even if there’s just 1 App UI that calls your API, that’s a good separation of concerns.

In this “mobile app” era, APIs are going to “the” way to build an ecosystem around your applications,whether it’s a startup with a great idea or an enterprise application that serves consumers and other users. Think about the possibilities if a company like Comcast provided access to viewership data once a consumer allows access to it in return for recommendations that are generated based on your Social graph. I’m sure there’s startups and companies already doing this but having an API builds an competitive ecosystem that makes your data and service successful and widely adopted.