Application Key
- Sanjay Dalal (Unlicensed)
CollectionSpace services expose web service (RESTful or SOAP) based Application Programming Interfaces (API) to facilitate the consumption of the services by various kinds of applications. It is expected that the applications consuming these services could be written in any programming or scripting language providing libraries to access a web service (HTTP/XML/JSON). While exposing the CollectionSpace APIs in the form of web services definitely opens up the possibilities of unforseen creative and wide usage, it also poses some challenges to the deployers of the services as well. These challenges are related to fulfilling the operational and/or business specific service level objectives (SLO).
Service level objectives
According to Wikipedia, Service level objectives (SLOs) are a key element of a service level agreement (SLA) between a service provider and a customer... SLOs are agreed as a means of measuring the performance of the Service Provider and are outlined as a way of avoiding disputes between the two parties based on misunderstanding. SLOs are specific measurable characteristics of the SLA.
Requirements
In order to fulfill the SLOs such as availability, fairness, throughput, frequency, response time, etc., for various CollectionSpace services, the service layer should take precautions against over/improper usage of these services by certain consumers as well as prevent hijacking of service resources by certain consumer(s) to avoid starvation of resources for other consumers. The required safe guards could be put in place by following one or more of the following guidelines/rules:
- Provide access to a service only to pre-registered (vetted) domains consuming services
- Differentiate the access offered based on the type of the service consumer (commercial, non-commercial, individual, community partner, development partner, etc.)
- Provide various qualities of service such as availability guarantees, response time, throughput, etc. based on the type of the service consumer
- Track the service usage to know who uses what from where and when. This could be useful for billing/royalty collection purpose as well.
- Meter the service usage to enforce fairness among and across a class of service consumers (non-commercial, commercial, geographic region, etc.)
At the core of the above listed requirements, is the requirement to uniquely identify and authenticate each consumer application (not necessarily a user) accessing one or more CollectionSpace services using public APIs.