Hi,
I'm currently involved in integrating SharePoint with IBM Connections and I'm having a lot of fun trying to figure out all the possibilities. Since these integration considerations are not specific to SharePoint/IBM Connections, I'll blog a series of posts which will be rather short or rather long according to the topic I'm focusing on.
In this post, I'm going to focus on CORS (Cross Origin Resource Sharing) and SharePoint 2013 considering that one way to consume SharePoint data from non Microsoft products is to leverage the SharePoint 2013 REST APIs. Microsoft solutions could make use of the CSOM but it's not available when working with Java. Moreover, CORS is bi-directional while the CSOM in combination or not with the App Model is meant to consume SharePoint data from remote but not the other way around. Moreover, the App Model is also most suited when remaining in the Microsoft stack. I know that you can build provider-hosted apps with any technology including JAVA but it's probably not the easiest path.
So, I'll take the angle of a remote application (say java) that tries to consume SharePoint's REST API. But the same kind of technique can be used if you wish to work the opposite way (from SharePoint to a Remote App exposing some REST APIs)
If you haven't read my previous posts of this integration challenges serie (click the Integration tag), you'd better do it to have a full picture of the possibilities. I'm not going to explain what's the same-origin policy anymore.
CORS recap
In a nutshell, CORS is a communication between a browser and a server based on specific HTTP headers. The below schema shows a basic CORS conversation between a browser and a server:
where:
- 1) The preflight options request is sent depending on several factors such as the VERB being used (GET,POST,PUT,DELETE) and some custom headers emitted by the client request. Also, this preflight request can be cached using the max-age attribute.
- 2) The server *should* return a 200 response including the expected CORS http headers.
- 3) According to the headers returned by the server in the response, the browser will perform or not the actual cross-domain request
- 4) The response from the remote domain
As this schema shows, this looks quite simple. On the server-side you can control which origin is allowed and which methods. So, you could for instance decide that GET and POST are allowed but not PUT and DELETE.
You could allow some specific HTTP Headers or not etc..