Is this really an API? Well, sort of. The help content is pushed out into a JSON file that other websites and applications can easily consume. The endpoints don't deliver different data based on parameters added to a URL. But the overall concept is similar to an API: you have a client requesting resources from a server.
Note that in this scenario, the help is openly accessible on the web. If you have a private system, it's more complicated.
To deliver help this way using Jekyll, follow the steps in each of the sections below.
## 1. Create a "collection" for the help content (optional)
A collection is another content type that extends Jekyll beyond the use of pages and posts. Here I'm calling the collection "tooltips." You could also just use pages, but if you have a lot of content, it will take longer to look up information in the file because the lookup will have to scan through all your site content instead of just the tooltips.
Add the following information to your configuration file to declare your collection:
```liquid
collections:
tooltips:
output: true
```
In your Jekyll project, create a new folder called "_tooltips" and put every page that you want to be part of that tooltips collection inside that folder.
## 2. Create pages in your collection
Create pages inside your new tooltips collection (that is, inside the \_tooltips folder). Each page needs only a unique `id` in the frontmatter. Here's an example:
{%raw%}
```liquid
---
id: basketball
---
{{site.data.definitions.basketball}}
```
{%endraw%}
You need to create a separate page for each resource you want to deliver. In this setup, the definition of basketball is stored in a data file call definitions inside the \_data folder so that we can re-use it in other parts of the help as well. (This additional re-use is covered later on this page.)
## 3. Create a JSON file that loops through your collection pages
Add the following to a file and call it tooltips.json:
```
{% raw %}
---
layout: none
---
{
"entries":
[
{% for page in site.tooltips %}
{
"id" : "{{ page.id }}",
"body": "{{ page.content | strip_newlines | replace: '\', '\\\\' | replace: '"', '\\"' }}"
} {% unless forloop.last %},{% endunless %}
{% endfor %}
]
}
{% endraw %}
```
This code will loop through all pages in the tooltips collection and insert the id and body into key-value pairs for the JSON code. Here's an example of what that looks like after it's processed by Jekyll in the site build: tooltips.json.
{{site.data.alerts.tip}} Check out Google's style guide for JSON. These best practices can help you keep your JSON file valid.{{site.data.alerts.end}}
Store this tooltips.json file in your root directory. You can add different fields depending on how you want the JSON to be structured. Here I just have to fields: `id` and `body`. And the JSON is looking just in the tooltips collection that I created.
When you build your site, Jekyll will iterate through every page in your _tooltips folder and put the page id and body into this format.
You could create different JSON files that specialize in different content. For example, suppose you have some getting started information. You could put that into a different JSON file. Using the same structure, you might add an `if` tag that checks whether the page has frontmatter that says `getting_started: true` or something. Or you could put it into a separate collection entirely (different from tooltips).
By chunking up your JSON files, you can provide a quicker lookup, though I'm not sure how big the JSON file can be before you experience any latency with the jQuery lookup.
## 4. Allow CORS access to your help if stored on a remote server
When people make calls to your site *from other domains*, you must allow them access to get the content. To do this, you have to enable something called CORS (cross origin resource sharing) within the server where your help resides.
In other words, people are going to be executing calls to reach into your site and grab your content. Just like the door on your house, you have to unlock it so people can get in. Enabling CORS is unlocking it.
How you enable CORS depends on the type of server.
If your server setup allows htaccess files to override general server permissions, then create an .htaccess file and add the following:
```
Header set Access-Control-Allow-Origin "*"
```
Store this in the same directory as your project. This is what I've done in a directory on my web host (bluehost.com). Inside http://idratherbetellingstories.com/wp-content/apidemos/, I uploaded a file called ".htaccess" with the preceding code.
After I uploaded it, I renamed it to .htaccess, right-clicked the file and set the permissions to 774.
To test whether your server permissions are set correctly, open a terminal and run the following curl command pointing to your tooltips.json file:
```
curl -I http://idratherbetellingstories.com/wp-content/apidemos/tooltips.json
```
If the server permissions are set correctly, you should see the following line somewhere in the response:
```xml
Access-Control-Allow-Origin: *
```
If you don't see this response, CORS isn't allowed for the file.
If you have an AWS S3 bucket, you can supposedly add a CORS configuration to the bucket permissions. Log into AWS S3 and click your bucket. On the right, in the Permissions section, click **Add CORS Configuration**. In that space, add the following policy:
```xml
Basketball
``` Notice that I just have `id="basketball"` added to this popover element. Developers merely need to add a unique ID to each tooltip they want to pull in the help content. Either you tell developers the unique ID they should add, or ask them what IDs they added (or just tell them to use an ID that matches the field's name). In order to use jQuery and Bootstrap, you'll need to add the appropriate references in the head tags of your page: ```js