"Rest and be thankful."
― William Wordsworth
On a number of occasions, my unified communications 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.
Today, I'll dig a little deeper into Web services, exploring 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. Trust 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.
In the world of unified communications as a service (UCaaS), folks like RingCentral, Twilio, Zang, and Flowroute are blazing the trail with their comprehensive APIs built on RESTful Web services.
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. Most developers today 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:
In terms of HTTP, REST predominantly uses four methods: POST, GET, PUT, and DELETE. You will sometimes hear this referred to as CRUD, which stands for create, read, update, and delete. The mapping of HTTP methods to REST functionality is as follows:
A very simplistic REST call that adds a user to a contact list might look as follows:
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. Personally, I will choose JSON any day of the week, but XML interfaces have been extensively deployed.
Since security is paramount, all REST messages should be sent using HTTPS. This prevents someone from "sniffing" the LAN or WAN and obtaining potentially sensitive data.
There are a number of ways you can play with Web services before you put any money into it. If you are a programmer, your preferred language most likely contains built-in support for writing Web services clients and servers. As a Java programmer, I am immersed in the Apache CloseableHttpClient object and its many methods.
However, you can explore Web and cloud services without a lick of programming knowledge. One of the most popular alternatives to coding is Google's Postman. Postman provides an easy to use GUI (Graphical User Interface) that allows you to write, run, and test every imaginable combination of commands, headers, and message bodies. It's my go-to tool when I want to explore a cloud API before committing to writing a real application. Postman allows me to work out the message flows to and from a cloud service that is easily translated to Java code.
Curl is another popular tool for exploring Web services. It's a tad more complicated than Postman, but as a command line tool, it is sometimes the best choice for testing purposes.
At this point, I have covered all that I want to say for a Web services primer. If you've read this far, I hope you walk away from this article with these four concepts:
That's enough for now. I hope this furthers your knowledge of all that goes into unified communications. Clearly, it's not just SIP and RTP.
Andrew Prokop writes about all things unified communications on his popular blog, SIP Adventures.
Follow Andrew Prokop on Twitter and LinkedIn!
@ajprokop
Andrew Prokop on LinkedIn
