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
The options:
- Server side Proxy
- JSONP
- Cross Origin Resource Sharing (CORS)
- Your Javascript library (JQuery etc.) would create a new <script> DOM element with “src” attribute set to
http://api.app.com/getSomething?callback=javascriptFn - The API will receive a HTTP GET request, process the request and generate the JSON response
- 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'});
- The Browser receives the response and because the content type is set to JavaScript, it will attempt to call the function called
javascriptFnpassing in the JSON response. The function can now update the DOM/do any processing with the data as it deems fit.
Access-Control-Allow-Origin: http://example.com:8080
There are additional headers that can be sent as part of the response. Below are some additional headers:
Access-Control-Allow-Origin
Access-Control-Allow-Credentials
Access-Control-Expose-Headers
Access-Control-Max-Age
Access-Control-Allow-Methods
Access-Control-Allow-Headers
function callApi(){
$.get( 'http://api-dot-com.herokuapp.com/apiCall',
{requestParam: 'Parametervalue'},
function(responseJson){
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.
