So far in this book, we have worked with static data that is hard-coded directly into the TripLog app itself. However, in the real world, it is rare that an app depends purely on local static data—most mobile apps get their data from a remote data source, typically an API. In some cases, an app may talk to a third party API, for example, that of a social network. Alternatively, developers sometimes create their own API to make data available for their apps. In this chapter, we will create a simple API in the cloud that we can connect to and retrieve data from in the TripLog app.
Here is a quick look at what we will cover in this chapter:
Almost all mobile apps communicate with an API to retrieve and store information. In many cases, as a mobile app developer, you might just have to simply consume an API that already exists. However, if you're building your own service, as opposed to consuming someone else's, you will need to create your own API. There are several ways you can create an API, several places you can host it, and certainly many different languages you can develop it in. For the purposes of this book, we are going to create an API in the cloud using Microsoft Azure App Services. Azure App Services contains many products and features, one of which is called Mobile Apps (formally known as Azure Mobile Services).
Azure Mobile Apps provide a very quick and easy way to get a fully functional backend service up and running in a matter of minutes. You can create the backend service using either Node.js or .NET. Because the primary focus of this book is developing a mobile app, I will not spend a lot of time explaining all the granular details of the Azure Mobile Apps Service. So, in this section, we will just cover the basics needed to create a simple, "out-of-the-box" API that we can connect our app to later in this chapter.
In order to follow along with the steps in this chapter, you will need to have an Azure account. If you don't already have an Azure account, you can create one for free at https://azure.microsoft.com/en-us/pricing/free-trial/.
Once you have an Azure account, the first thing you need to do is go to the Azure portal in a web browser.
Once you have created a new Mobile App in Azure, it will, by default, have no tables or data. Before we can start working with the API, we will need to create a new table that will store our data.
When you configure an App Service to use Easy Tables from within the Azure Portal, it will automatically create a Node.js backend for the service. If you want to use a .NET backend instead, take a look at the documentation at https://azure.microsoft.com/en-us/documentation/articles/app-service-mobile-xamarin-forms-get-started/#configure-the-server-project.
By selecting the Allow anonymous access permission, we are making the API available without providing any specific authentication headers in the HTTP request. In the next chapter, we will add authentication to both the API and the mobile app, but for now, we will simply employ anonymous access.
Now that we have created an API in Azure and set up a data table within the service, we can start making calls to the API and getting responses. Before we start making calls to the API from within the TripLog app, we can test the endpoint by making GET
and POST
HTTP requests to it using the command line or a REST console.
There are several REST consoles to choose from if you don't already have one installed. I typically use either JaSON (https://github.com/shanebell/JaSON) or Postman (http://www.getpostman.com/). Both are available as Chrome browser apps, making it really easy to install and use them.
GET
request to the API endpoint for the Entry table using the following URL and header:GET https://<your-service-name>.azurewebsites.net/tables/entry --header "zumo-api-version:2.0.0"
200
status code and an empty collection in the response body, as follows:[ ]
POST
request to the same API endpoint with an Entry
JSON object included in the body of the request. The service will automatically create the appropriate columns within the Entry table when we insert the first object:POST https://<your-service-name>.azurewebsites.net/tables/entry --header "zumo-api-version:2.0.0" --data { "title": "Space Needle", "longitude": 47.6204, "latitude": -122.3491, "date": "2015-07-03T00:00:00.000Z", "rating": 5, "notes": "Wonderful site to see" }
We should receive back a 200
status code with the new item we added in the response body.
GET
response to the Entry
endpoint:GET https://<your-service-name>.azurewebsites.net/tables/entry --header "zumo-api-version:2.0.0"
We should receive back a 200
status code; however, now the response body has a collection containing the new item we added:
[ { "id": "c4a0595d-ac77-4c5b-9d94-f70374e522ab", "createdAt": "2015-07-05T21:37:41.946Z", "updatedAt": "2015-07-05T21:37:41.977Z", "version": "AAAAAAAACBQ=", "deleted": false, "title": "Space Needle", "longitude": 47.6204, "latitude": -122.3491, "date": "2015-07-03T00:00:00.000Z", "rating": 5, "notes": "Wonderful site to see" } ]
Notice that after we added the new record to the backend service, it was automatically given an id
property, along with a couple of other properties. The id
property serves as a unique primary key for the record. We will need to update the TripLogEntry
model in our TripLog app to account for this new property.
string
property named Id
to the TripLogEntry
model class, as follows:public class TripLogEntry { [JsonProperty("id")] public string Id { get; set; } public string Title { get; set; } public double Latitude { get; set; } public double Longitude { get; set; } public DateTime Date { get; set; } public int Rating { get; set; } public string Notes { get; set; } }
Now that we have a live backend service that we can communicate with via HTTP, we will update our TripLog app so that it can send requests to the API to add and retrieve log entries.
18.118.37.154