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
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:
See also: To learn more about REST principles, start with Wikipedia.
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.