Web Services

REST by far is the most efficient and seamless way for disparate and distributed systems to exchange or communicate information. Most interactions are characterized as request-response-action-based exchange. And invariably, there is a client (requesting an action or resource) and the server (providing the response or resource) to complete an exchange between two endpoints over HTTP protocol. In that manner, the Loom REST API, then, allows you to interact with the Continuuity Loom system from an administrative and user perspective. You can pretty much do everything that a UI can do using these REST interfaces.

Since the API is based on REST principles, it’s very easy to write and test applications. You can use your browser to access URLs, and use pretty much any http client in any programming language of your choice to interact with the API

Base URL

All URLs referenced in the documentation have the following base:

http://<loom-server>:<loom-port>/v1/loom

In addition, two headers must be sent to all REST endpoints. The first is X-Loom-UserID and is used to specify the id of the user making the request. The second is X-Loom-ApiKey and is used to specify the api key used to communicate with the server.

Note

The Loom REST API is served over HTTP. In the near future, the Loom APIs will be served on HTTPS to ensure data privacy, and unencrypted HTTP will not be supported.

RPC Calls

In addition to the standard REST endpoints, a few RPC functions are available to obtain cluster information.

About REST (REpresentational State Transfer)

We designed the Loom API in a very RESTful way, so that your consumption of it is simple and straightforward.

From Wikipedia:

REST’s proponents argue that the Web’s scalability and growth are a direct result of a few key design principles:

  • Application state and functionality are divided into resources
  • Every resource is uniquely addressable using a universal syntax for use in hypermedia links
  • All resources share a uniform interface for the transfer of state between client and resource, consisting of
  • A constrained set of well-defined operations
  • A constrained set of content types, optionally supporting code on demand
  • A protocol which is:
  • Client-server
  • Stateless
  • Cacheable
  • Layered

REST’s client/server separation of concerns simplifies component implementation, reduces the complexity of connector semantics, improves the effectiveness of performance tuning, and increases the scalability of pure server components. Layered system constraints allow intermediaries-proxies, gateways, and firewalls-to be introduced at various points in the communication without changing the interfaces between components, thus allowing them to assist in communication translation or improve performance via large-scale, shared caching.

REST enables intermediate processing by constraining messages to be self-descriptive: interaction is stateless between requests, standard methods and media types are used to indicate semantics and exchange information, and responses explicitly indicate cacheability.

If you’re looking for more information about RESTful web services, the O’Reilly RESTful Web Services book is excellent.