We store cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. For more information on the information we collect, see our privacy policy here.
Strategies for Mobile Applications and Sitecore Part 1
Read Time
Share
Recently Velir had the opportunity to build Mobile Applications for one of our very prominent clients. One of the challenges was an interest in supporting iPhone, Android, and Blackberry devices. Our content is stored in Sitecore, so we wanted to retain this as the single source of content. Our goal was to build a single API in Sitecore to support the Mobile Applications and which can be reused for additional devices in the future. Indeed, when it became time to build the iPad Application in a later phase, the API proved to be completely reusable.
At a high level, the requirements included:
Sitecore continues to be the single source of content.
The Mobile API is to be built using the Sitecore API and the custom .NET code that already powers the website
The Mobile API needs to be device agnostic. We're originally targeting clients that will be built in Object C (IPhone) and Java (Android/Blackberry)
One of the great things about Sitecore, and ideally why we would want to use any CMS, is the ability to maintain our content in a single environment, then to reuse that content in a variety of environments and mediums including Web, RSS, Newsletters, Print Media, Social Media, and this article's topic: Mobile Applications.
Restful API
The foundation for building this API was to prescribe to the RESTful pattern. This can be thought of as a Design Pattern for building reusable APIs. Some important aspects of Design Patterns in general include:
Shared common language between developers. (If I use Design Pattern "A" and the next developer knows Design Pattern "A", then there will be certain constructs and vocabularies that are assumed. Essentially we both speak the same language)
A Design Pattern is a structure that has been found acceptable for solving a particular problem.
A Design Pattern is robust; it has withstood the test of time and analysis.
As a Design Pattern, building a Restful API fits in well with our goals as many of its tenents will be beneficial to us. Some of the key tenents that we are interested in include:
Stateless: Our Mobile Apps will not be reliant on session data, a simple request and response is all that his required.
JSON/XML: The response should be an abstraction of the data that is easily consumed.
HTTP Methods: Also called verbs, the RESTful web methods should use GET/POST/PUT/DELETE as intended. For example, calling GET should only retrieve information. It shouldn't be used to create or delete records.
Directory Based URIs: With RESTful, the directory and filename is the API call. This fits in very well with Sitecore since Sitecore's URI structure already mirrors the content tree.
Take the next step on your digital marketing journey. Reach out.
We leverage design and technology to set you on the path to digital success by using them to connect your audiences to a world of engaging content.
We'll be looking at a few places where we configure Sitecore to support the RESTful API. This part is straightforward and proves to be a natural fit within Sitecore which is a big win. It includes the Device Configuration, Presentation/Sublayouts, and the Content Tree structure.
Device Configuration
Since browser requests look exactly the same as RESTful requests, we need a way to distinguish when our Mobile App is issuing the request. RESTful recommends using the ACCEPT header which can then ask for JSON or XML instead of the usual HTML. However in Sitecore what we really want to do is to call a different sublayout which will be responsible for returning JSON/XML instead of HTML. Sitecore makes it easy to do by using the Device Configurations. Here we can identify our device one of two ways, either by User-Agent or by Query Param. We decided to use the query param "api=1". Thus when Sitecore sees the param it can switch to the sublayouts we've specified for handling Mobile API requests.
Presentation Settings
The Default Device in Sitecore generally contains layouts/sublayouts that are used for the HTML rendering of the website. Now that we have a MobileAPI Device we can use this to similarly store the layout/sublayouts we want to use to handle our API Request. In the following picture we focus in on the MobileAPI devices' layout and sublayout for an Article page.
Content Tree Design
As mentioned earlier, the synergy between the way that Sitecore constructs URLs from the Content Tree path and the RESTful API approach to web method calls is important. If we want to retrieve a list of all Experts for example, we would issue a request to the node representing the Experts folder such as: http://www.rilev.edu/experts.aspx
However if we wanted an individual Expert, the method call would extend upon this path to include the specific Expert.
For Example: http://www.rilev.edu/experts/ddelay.aspx
(Note that the /a/ has been stripped from the request. The /a/ is important in the Sitecore content tree for organizational and performance purposes. It is okay to keep this in the request, but isn't required. So for simplicity and readability, we remove this by adding a custom ItemResolver class to the pipeline in Sitecore.)
This is it for Part 1. In Part 2 of this blog post we'll delve deeply into several technical topics such as the API Architecture, Caching Strategy & Use Cases.
