On a number of occasions, my blog articles have used terms such as web services, SOAP, REST, and RESTful. Without providing much explanation, I’ve stated that these are methodologies and tools that allow a client application to access a remote service. For example, Avaya SIP telephones use web services to store and retrieve data from Personal Profile Manager (PPM). The telephone acts as a client to a service that executes as part of the Avaya Session Manager. PPM web services allow a telephone to perform functions ranging from adding a name and number to a contact list to retrieving the telephone’s button assignments.
For more information on PPM, please refer to my article, Understanding Avaya’s Personal Profile Manager (PPM).
Today, I plan on digging a little deeper into web services in terms of what they are and how they work. This can be a fairly complex subject, but the basics are pretty straightforward and having a decent background will help you in your overall understanding of unified communications platforms. Believe me, all the good ones support a collection of web services interfaces.
The term web services should be self-explanatory. These are services that are available over the Internet (web) or an enterprise’s intranet. I already gave the example of PPM, but web services are plentiful outside of telephony. You’ve used Google Maps before, right? Google offers a web services interface for map access and data retrieval. Microsoft offers a similar interface for its Bing maps. The social media giant, Twitter, advertises a myriad of web services to retrieve tweet data and statistics based upon a variety of parameters. Think of a major player on the web and I bet you will find that they support their own web services for data retrieval and manipulation.
Web services are built on the same protocols that your browser uses. Http is used for unencrypted access and https is used when you require a secure, encrypted connection from client to server. Using these protocols allows web services to pass through intermediaries such as data firewalls.
Web services are implemented in two distinct fashions – SOAP and REST. SOAP (Simple Object Access Protocol) came first and for many years was the predominant way to access web services. REST (Representational State Transfer) came along after SOAP, but most developers are moving to REST because of its simplicity, statelessness, and ability to scale to support large, distributed computing environments.
A comparison of SOAP and REST is beyond the scope of what I want to accomplish in this article. There are plenty of those discussions on the Internet and I invite you to explore them. For this article, I will focus on REST since it appears to be winning the API (application programming interface) war.
RESTful web services follow four basic design principles:
- Use HTTP methods explicitly
- Be Stateless
- Expose directory structure-like URIs
- Transfer XML, JSON (JavaScript Object Notation), or both
In terms of HTTP, REST predominantly uses four methods – POST, GET, PUT, and DELETE. You will sometimes hear this referred to as CRUD. CRUD stands for create, read, update, and delete. The mapping of HTTP methods to REST functionality is as follows:
- To create a resource on a server, use POST
- To retrieve a resource from a server, use GET
- To change the state of a resource or to update it, use PUT
- To remove or delete a resource, use DELETE
A very simplistic REST call to add a user to a contact list might look as follows.
POST /contacts HTTP/1.1
Host: myserver
Content-Type application/xml
<?xml version=”1.0”?>
<user>
<name>Andrew Prokop</name>
</user>
Notice how this call uses XML to describe the new contact. As I stated above, REST also supports JSON to describe the user object. As with the pros and cons of SOAP and REST, I will let the reader do his or her own research into XML vs. JSON.
Throughout the day, an Avaya SIP telephone will use REST to query PPM for configuration information and update PPM data stores with user provided information. Unless a button or a soft-key suddenly changed, the user of the telephone would be unaware of these background activities.
Since security is paramount, all PPM REST messages will be sent using https. This prevents someone from “sniffing” the LAN and obtaining potentially sensitive data.
At this point, I have covered all that I want to say about web services. If you’ve read this far, I hope you walk away from this article with these four concepts.
- Web services allow clients (e.g. SIP telephones) to access services (e.g. PPM) in a loosely connected manner.
- Web services are built on the web protocols http and https.
- There is no limit to the kinds of interfaces that web services can facilitate. Communications systems offer web services. Social media platforms offer web services. Retail services offer web services. Contact centers offer web services. The list goes on and on.
- The two predominate ways of implementing web services are SOAP and REST. SOAP got here first, but REST has the wind in its favor.
Thank you for reading. I hope this furthers your knowledge of all that goes into unified communications. It’s not just SIP and RTP.
Tao, Zen, and Tomorrow 