Introduction to Web Services and REST

I'm back with a new series of tutorials! This series of posts aims to discuss web services (specifically REST). I am in no-part an expert nor do I claim to be. Feel free to reach contact me for any errors or feedback (krisviceral at gmail).

Web services are becoming more and more popular in the past few years. Why wouldn't it be? As the past few years have showed, people have more than a few computing devices with them at any one time. No longer are people limited to desktops and laptops when they want to check their email, Facebook, etc. With that in mind, people expect different things this day and age. People expect to be able to check all these things on a series of devices from tablets to smartphones to even refrigerators.  Web services helps application developers distribute their product or content on a variety of different platforms. How? Web service decouples the data to the application. Different applications can consume the same data from a standard source.

What is a Web Service?

Wikipedia states that a "web service" is a method of communication between 2 devices over the web. Services can be accessed over a web or net address and are typically always-on. With that definition, we can grab the key terms to defining a web service are "communication", "net address" and "always-on".

The communication aspect of a web service means that one device is the producer (service) and the other is the requester (client). The information passed can be an XML a JSON (JavaScript Object Notation) or a media type depending on the type of web service implementation. Net address means that the service can be accessed through (you got it!) a web URL. Unlike a web application, if you access a web URL of a web service (for example REST) you are getting simply the data or resource in whatever format the service brings. It's up to another application (a client) to transform the data and make use of it. Imagine going to Google.com/user/krisviceral and you simply get a string saying "name:Kris last name: Viceral". Always-on as the name implies is always running. You don't fire up a service just when you need it (ala traditional desktop application).

_Note: Service refers to the web service. Client refers to the consumer of the web service. _

Service-Oriented-Architecture (SOA)

Web services are part of the design/architecture pattern called SOA that focuses on making resources accessible through (again) services. SOA handles discoverability of different services and their interaction to each other. Services under SOA are built to be unassociated and loosely coupled. This will allow you to build a complete web application by combining/integrating several of these services.

[caption id="" align="aligncenter" width="455"] WS Example Flow. Click to enlarge.[/caption]

Example Web Service and Client: Twitter

If you want to build your own Twitter application you can build it through calls through Twitter's web service API. After you've built the initial UI, you can load the timeline tweets by calling their REST API by doing a "GET" call. What you'll get is a series of objects (tweets) in JSON. A tweet object would contain the user, the tweet itself (140 chars), date and time and so on. Now since you now have the data, it's your choice on how your application will read this and show it in the UI. The same thing goes for posting a new tweet. You send an object containing the needed to the API and it'll take care of the rest.

Web services that are APIs are like exactly like calling a regular API except that you are doing it consuming and interacting with it through the web instead of importing a class or file in your application.

[caption id="attachment_1073" align="aligncenter" width="291"] Web Services Diagram. Close enough. Click to enlarge[/caption]

Advantages and Disadvantages of Web Services

For me, the 2 biggest benefits of designing an application through web services-client are platform-independence and maintainability. Building a web service first would make it easier as a developer to make your content reach different platforms. Essentially, since the generic processes and data is separate, all you need to do is to build a "view" in the native platform. Once you've build the service, you can reuse it on as many different platforms as you want. In this day and age of having a smartphone, computer and more, that benefit would be pretty nice to have. Another benefit is maintainability. Since the service is separate from the client, this makes it easier to maintain. If you make an update to the native application or web service client, you don't need to touch the service at all. On the service end, if you want to make improvements to make it faster to read or process data the client doesn't need an update to take advantage.

What are the disadvantages then?  I've only worked with web services and I've only used REST for a short time, so I haven't really seen all or most of the roadblocks yet. For me the biggest roadblock and  the difficulty lies in remembering that it is different architecturally from a standard web mvc application. The languages you are using may be the same but the style you are building it is different. Security on a web application is different from the security you will place in your web service. Remember that you don't have a front-end so you'll use different things for authentication and authorization. On the testing side, you are testing the service differently from the client web application. In a web service, you are checking if the data you are producing is correct when it arrives to the client. You are also testing the consumption of data and handle incorrect parameters, data, etc. Building the web service is again more like building an API.

Does creating a web service make everything more complex? Yes. For me, it's not too complex that it makes it seem like a herculean effort to pull off. Implement a web service using REST is not too hard. Plus, it's fun to learn.

[caption id="attachment_1083" align="aligncenter" width="300"] More funky acronyms: SOAP and REST.[/caption]

Types of Web Services Implementation

There are two types of popular implementations of web services namely SOAP and REST. SOAP stands for Structural Oriented Amnesia Pepper... okay so maybe not. It's actually Simple Object Access Protocol. Web services can be implemented through the SOAP protocol which transfers messages through the HTTP or SMTP protocol and uses XML as its message.  SOAP itself looks like a beast with tons of things you need to understand to be able to implement. I have not worked with SOAP yet so I'll stick with discussing REST.

REST, Something Nice To Do Right Now

REpresentation State Transfer or REST for short, is an architecture style for creating distributed systems. Why style? REST is not a protocol (it would be called RESTP if it was) nor a standard. Let's discuss all the things about REST one by one.

Client-Server, Resources and HTTP Methods

As in the example above, there consists a client and a server (providing the service). They communicate through the HTTP methods primarily the GET, POST, PUT  and DELETE. They access "resources" on the server. In REST, everything is a resource. Not just photos, videos and files but even objects representing data is a "resource". Think of it as being able to  access domain objects but by calling a service instead of directly creating it in your code.

If you don't happen to know, a domain object is a plain-old-java-object (POJO, had enough acronyms yet?) that is used to represent data in the database. For example, you'll have a USER object that contains String name, Int userId, String email, etc. In a standard web application, you would have a technology/tool called ORM so that your object will be created almost automagically using the different tables in your database.

Again, in a web service, you are calling the object though the service. You can get it through a variety of media types. Depending on the server, you can grab resources through JSON, XML, Plain ol' HTTP Text and more.

To Be Continued...

On the next part of the series, I'll dive in deeper to REST by discussing  JAX-RS (the java implementation of REST) along with the frameworks for building REST with Java, namely Spring and Jersey.