Have you ever wanted to create a service that could be shared on multiple platforms (e.g. a mobile and a web platform, or even multiple web applications)? API is the key.
I’ll be starting a three-part tutorial (on Trailblazing) on how to consume a web API. The API we will be consuming is a simple rail API I built (I try not to make things complicated). You can follow along with the 3 part tutorials, and use the API service I’ll be using:
API endpoints:
http://jobwater.herokuapp.com/api/jobs
http://jobwater.herokuapp.com/api/jobs/74
Jobwater is a simple application that lets you post a Job with a job title, phone and email (nothing serious).
[Suggestion: after the tutorial you can use any API service you prefer or build your own API service with the server-side scripting language of your choice, and follow these same steps to consume your API]
· 1st part: Call API endpoint from a NodeJS – Express application. We will create a read functionality from the NodeJS app to consume all posts from the API service. All the posts will be displayed as JSON format in our NodeJS app. You can then decide to use a templating language (e.g. EJS) to generate HTML markup for the JavaScript file [I won’t be doing this till part 3]
· 2nd part: Call API endpoint from a PhoneGap application (with jQuery). Interested in converting that API service/web application to a mobile app? This is it right here. Just like the first part, we won’t be doing any html output and styling [that’s part 3].
· 3rd part: Call API endpoint from a PhoneGap application (with jQuery) and display as HTML format for styling. In this part, we will be reading all posts, as well as single post. We will be able to view all the posts, and then click on the title to redirect us to the single post to read its content, and then there’s a back button to take us back to all posts.
Before we jump into our 3 part tutorials, why don’t we talk a bit more about APIs.
API allows you to distribute your content which has been created once, to be published on many channels. Channels may include multiple applications (mobile or otherwise) and websites.
For example, you want to build a blogging application that can serve multiple client applications; you could simply build the blogging service with the applications on their respective platforms (e.g. mobile and web) and with their respective tools (e.g. NodeJS, PHP, Objective-C, Java etc.) or you could just build an API service and make API calls from the external service.
Using API helps you separate your application into micro services so that you can make API calls to these microservices and show it in a main app that handles the request. This way if one of the features of your main application break, it won’t break the whole application. You know a micro service is the issue, while your main app is still running/working. This way, you can focus your efforts on fixing the micro service that's displaced.
Compared to monolith applications, if you have a feature break on the backend, it affects the whole application. If there's a lot of nesting within your application, this means more debugging and fixing.
API serves you endpoints, such that if you decide to have a web and mobile app version of your project, you can make calls to your API service. For example, you want PhoneGap to serve the API endpoints, you can then build the PhoneGap App into an android/iOS app. This step will be covered in the part 2 and 3 of the 3 steps tutorial.
Part 1: http://www.trailblazing.in/blogs/consuming-api-from-a-nodejs-express-application
Part 2: http://www.trailblazing.in/blogs/consuming-api-with-jquery-on-phonegap
[ Part 3 coming out soon ]
NB: PhoneGap lets you build mobile apps with html CSS and JavaScript. . . [check out my tutorial on how to build a simple PhoneGap game]
NB: Monolith applications are applications that have been built and packaged as one big application and has all the services it requires from within.
About ohiodn8
Ruby on Rails developer, AWS Engineer, anything fun, music, a little bit of mobile game. . .