Why REST with JSONP when you can CORS?

JSONP (JSON with padding) is a hack used by JavaScript developers by wrapping a JSON (JavaScript Object Notation) document within a function call. So, if the JSON document looked like {"givenName":"John", "familyName":"Smith"}, the JSONP for the same would be callback({"givenName":"John", "familyName":"Smith"}) (callback being the commonly used wrapper function). So, if you are familiar with JSONP, you will realize that it is used to make Cross-Domain calls where JSON is not accepted by the browsers if they come from another domain. Thus, AJAX requests across a different domain was not possible through JSON and hence using JSONP was the common hack.

The problem with using JSONP is that it is called as a JavaScript function response and hence you will not be able to use it as normal HTTP calls. That means you would not be able to send HTTP headers and that can be a problem at many places. There are hacks to deal with the problem, but these are best described as hacks. Another limitation of the JSONP hack was that you could only make GET requests and nothing more. Hence to make a standard, W3C created the CORS (Cross-Origin Resource Sharing) standard which nearly all modern browsers support.

The main issue with using JSON or AJAX (XHR – XMLHttpRequest) across domain was that browsers would not be able to acknowledge if the response was malicious or in response to the request that they made. The same-origin-policy, prevented making cross-domain requests. Then came CORS, a technique by browsers to check the origin policy first and then accept responses. So a server that wants to allow getting any type of HTTP request from another domain would list the domain or * in its HTTP response header as follows:

Access-Control-Allow-Origin: *
Access-Control-Allow-Origin: http://example.com:8080 http://foo.example.com

This means that there is some modification to be done on the server-side resource to add these headers to the response. Another point to note is that it works with XHR requests as well as client errors (4xx) and server errors (5xx).

Excellent examples on how to use CORS can be found at HTML5Rocks. On the server-side of things, you can find resources to enable CORS.

In Tomcat for a Java web application, you can enable CORS using the CORS Filter library. Basically you copy the jar file into Tomcat lib or WEB-INF/lib of your application and then add filters in your application’s web.xml or tomcat’s global conf/web.xml. For a resource which requires Basic Authentication and Cookies can be configured as follows:

<filter>
    <filter-name>CORS</filter-name>
    <filter-class>com.thetransactioncompany.cors.CORSFilter</filter-class>
    <init-param>
     <param-name>cors.allowOrigin</param-name>
        <param-value>*</param-value>
    </init-param>
    <init-param>
     <param-name>cors.supportedMethods</param-name>
        <param-value>GET, POST, HEAD, PUT, DELETE</param-value>
    </init-param>
    <init-param>
     <param-name>cors.supportedHeaders</param-name>
        <param-value>Content-Type, Last-Modified</param-value>
    </init-param>
    <init-param>
        <param-name>cors.exposedHeaders</param-name>
        <param-value>Set-Cookie</param-value>
    </init-param>
    <init-param>
        <param-name>cors.supportsCredentials</param-name>
        <param-value>true</param-value>
    </init-param>
</filter>
<filter-mapping>
        <filter-name>CORS</filter-name>
        <servlet-name>MyServlet</servlet-name>
</filter-mapping>

Instructions for Cookies in Safari can be challenge. A nice post to workaround can be found here.