Quick Start
Walking you through the steps of how to build a site or app lies beyond what we can cover here. We'll make reference to how we did things for the Fifth World website (which we built with JavaScript using Node.js, Express.js, and Passport.js, but you'll have to figure out how that maps to your own project yourself.
Example: The Fifth World Map
Let's say that you want to create a web app that shows all of the publicly-available locations listed on the Fifth World website. In this case, you really just need one endpoint: the Get pages endpoint. Since you just want the publicly-available locations, you don’t even need to authenticate.
Example: The Fifth World Writer's App
Let's say you want to provide a distraction-free writing environment specifically for writing stories set in the Fifth World. You have some ideas for soothing jungle sounds and a nice background and some subtle animations that you think will really help writers focus and feel the setting (actually, this sounds pretty great, maybe we should add it to our roadmap…)
For this app, you'll need to deal with authentication>. After all, you don't want every writer who uses your app to write stories credited to you, you want them to write their own stories. That means you'll have to give your users the chance to log in. That will mean making requests to the authentication endpoint to get a JSON Web Token. You'll have to keep this token handy. Cookies work great for a website or web app, but in this case we want to make a native app, so we store it as a variable on the device. Since the token expires after 15 minutes, we'll need to make a request to the renew authentication endpoint in the background a little more frequently than that to make sure that our token doesn't expire.
Next, the user goes to our lovely writing screen. Our writers might not know what they want to call their stories at first, so we don't bother them with such things just yet. We keep it local on the device and autosave every minute or so. But when you tell us your finished, you back out of the writing environment to a page that shows you all of your current drafts. From here, you can choose to publish a story. There we ask you for anything still missing that a page will need, like title, if we should make it the child of any other page, and tags like author, or if we should treat this as a chapter of a longer work. Once we have all of that, the user presses the Publish button, and our app makes a call to the Create a new page endpoint to publish the page.
After the user has published her first story, we have a list of stories in various states of publication — some she's begun on our app, some she's begun on the site, and some published. So now we need to make our list of drafts a little more complicated, combining the list we have locally on the device with the results of a call to the Get pages endpoint. Since we're supplying the user's token, we'll even get unpublished pages that she's created on the site that only she can see. We copy all of those pages to the list we keep on the device, and we add some data in the background that associates the unique path of a published story with the copy we're keeping locally, which also helps us tell which ones we've published and which we haven't.
Now when the user visits the page with her drafts, we make a quick check to the\ Get pages endpoint to potentially update our list, just in case anything has changed. And when she publishes changes to stories that she's already published, we use the path we've saved to know to send our request to the Update page endpoint(using the path we have for the published story) instead of simply posting to the Create a new page endpoint.