Supporting Client-side API and Linked Data Consumption
General JSON Support
Support of JSONP and/or CORS is essential for any API that should be available to client-side consumers. Without one of these technologies, API data is inaccessible to clients due to cross-server scripting errors.
All responses from the server must return at least an Access-Control-Allow-Origin header in order to allow client-side applications to interact with the data. This header specifies which domains the server is willing to interact with. Often the value of this header is set to "*", which means any domain may interact with the data. To control which actions a client can take, the server returns an Allow-Control-Allow-Methods header. Here, a server can specify which HTTP methods a client is allowed to perform.
OPTIONS / Host: viaf.org Origin: http://www.librarywebchic.net/
The server will respond with a set of headers that tell the client which operations it is allowed to perform on that resource.
Access-Control-Allow-Origin: * Access-Control-Allow-Methods: GET
CORS has several advantages over JSONP.
- It gives API developers the ability to make both read and write operations available to client-side API consumers.
- It gives API developers the ability to tightly control which client-side application can perform particular operations on particular resources. For example, you may only want domains you control to be able to write data via CORS.
For a more in depth look at CORS, take a look at the HTML5 Rocks site's Using CORS Tutorial.
Cache-Control is a header that allows API developers to define which resources can be cached, by whom and for how long. This is done via the Cache-Control header, which contains a number of directives. A few key directives are as follows:
- Max-age: The period of time that the response may be cached for, in seconds
- No-cache: Response can be cached, but requests for the same URL must check with the server to see if response has changed
- No-store: Response cannot be cached
- Public: Response can be cached (this typically doesn’t appear in responses because the presence of a max-age directive implies that a response is cacheable)
- Private: Responses can only be cached in a browser but not in an immediate cache (this typically is a response that contains user data)
When a client application makes a request to an API, the API returns a response with a specific Cache-Control header.
GET /viaf/102333412/ HTTP/1.1 Host: www.viaf.org Accept: application/ld+json
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Location: viaf.jsonld Cache-Control: max-age=604800 Expires: Thu, 04 Aug 2016 17:49:05 GMT Content-Type: application/ld+json Transfer-Encoding: chunked Date: Thu, 28 Jul 2016 17:49:05 GMT
Cache-Control is very useful for client-side applications because it allows developers to store data locally. By storing data locally, client-side applications are able to improve the performance of their applications.
In my next post, I'll look at an example application that leverages the fact that VIAF has added support for these technologies.
Senior Product Analyst