Aisle7 :: REST API from 30,000'
Implementation Guides

Search Documentation

REST API from 30,000'
Online > Reference > REST API from 30,000'

Overview of the Request and Display Process

Aisle7 ONLINE web products use server-side Web services technology to deliver requested Aisle7 content to your Web server, where it can be displayed in the context of your Web pages. The requested content resides on Aisle7 servers, but can be cached on your server(s) and refreshed periodically, including whenever the content is updated. This allows you to display current, objective health and wellness information within your own Web site without having to develop or maintain such content.

To implement an Aisle7 ONLINE web product, you create a server-side script that generates a HTTP request for an Aisle7 content resource. The request includes your unique API key (identifying you as a valid customer and your product), and several other optional arguments, including the content format to return (HTML, XML, or JSON), style options, and content link options. This script can be a complex script that is the template for your Web page or site, or it can be a simpler script that is referenced (included) in other templates.

Basic Aisle7 Request and Display Process

Principles and Style of the API

To the fullest extent possible, Aisle7 content services API adheres to REST principles. REST principles rely heavily on the inherent behavior and features that come with the HTTP protocol. They provide a well-known standard for API development and customer web client development. Following the terms and behaviors described for REST increases the predictability of your interactions with the API and leads to relatively simple and high quality implementations.

In particular, the Aisle7 API focuses on these aspects of REST:

  • Representing content as a hierarchical set of resources
  • Fully utilizing standard HTTP constructs

See also: To learn more about REST principles, start with Wikipedia.

Content is Represented as a Hierarchical Set of Resources

Aisle7 content is logically hierarchical, and as such, is self-discoverable. You can load a "root resource" and simply navigate through the different "content nodes," without needing a set of available content URLs to discover the content that is available to you.

For example, you can begin navigating through the content assets in your product using a request URI like:

The response to that request would provide a list of asset collections, each of which could be loaded by a request URI like:

The response to that request would provide a list of assets, each of which could be loaded by a request URI like:

Note that each request URI above shows a hierarchical “resource path” and the use of human readable content “slugs.” Resource paths and other aspects of URI requests are covered throughout this guide.

Standard HTTP Constructs are Fully Utilized

For example:

  • URI’s are used to provide all details about an API request, including version of the API, resource being requested, API key used in making the request, required format for the response, and other parameters.
  • HTTP status codes are used to completely describe the nature of the response. If an API key is not valid, a 401 UNAUTHORIZED is returned. If the resource requested does not exist, a 404 NOT FOUND is returned.
  • HTTP headers are used to provide metadata about requests and responses and to control caching.