August 6, 2016
Developer Skills You Must Know (But Didn't Learn in College) | Part 6: Communication Between Software

On March 22nd I gave a presentation to ASU's Software Developers Association which I called "What My Professors Didn't Teach Me - Developer Skills: What They Are, Why They're Important and What You Should Know About Them". The presentation provided an overview on seven different "developer skills" that I believe are necessary to succeed as a professional software developer. I define "developer skills" as those aptitudes between the "hard" technical skills of programming / hacking and the "soft" interpersonal skills of teamwork and communication. They are the things that a developer needs to know to succeed at his job outside of actually building software.

Over the next several weeks I will be writing a post on each of these proficiencies; each post will describe what the developer skill is, why I consider it to be necessary knowledge for the workplace, and what specific things you should learn. I plan to have links to tutorials or other websites that you can use to follow up.

The posts will be as follows:

Part 0: Introduction
Part 1: Version Control
Part 2: Ticketing Software
Part 3: Multi-Branch Development Workflow
Part 4: Libraries and Package Managers
Part 5: Working with Remote Computers
Part 6: Communication Between Software
Part 7: Securing Your Communication


The previous post discussed using tools like SSH or RDP to allow you to communicate with another computer by sending it commands and seeing the data that is returned. The focus of the post and the tools described therein are all centered around the idea of controlling the other computer, but the concept of communication between two machines is a much broader one. We're going to focus on that broader topic today by looking at different ways that software can communicate with other computers (e.g. computers other than the one the software is running on). This communication is generally known as "service calls".


What Is This?

To understand a "service call", it is helpful to consider a very similar bit of technology (actually, more or less the same technology) that is used every day - browsing the internet.

When you enter a URL in your web browser's URL bar, here's what happens:

  1. The web browser sends a message across the internet to the hosting software that "owns" that URL. This message contains data about what your web browser wants and is called a "request"
  2. The hosting software receives the message and inspects it, and decides what to do with it. Assuming the URL is not private or malformed, it will send some data back to your web browser over the internet.
  3. Your web browser receives the "response" message and the data it contains. This data is processed by the web browser and displayed on the screen in the form of a web page.

In other words, browsing the internet is simply a large series of request / response interactions between software running on your computer and different software running on other people's computers.


Image Credit: https://treehouselogic.wordpress.com

Why should this request / response interaction be limited solely to sending and receiving one type of data (web pages) for one type of purpose (browsing the web?) Wouldn't it be useful for your software to request data it needs from some remote authoritative source - say, have your stock trading software request stock quotes directly from the NYSE or other exchanges?

Of course this is useful, and that's why we have web services.

All web service technology works more or less in the way described above - the difference between them is the technology used to encode requests / responses, and the protocols used to send / receive the data. I will describe here the two major web service protocols, though as usual there are others.

SOAP: stands for "Simple Object Access Protocol". The SOAP protocol is not so much a communications protocol as it is an encoding standard. SOAP messages must be encoded in a special XML schema before beign sent in order for the SOAP-enabled recipient to receive it. After encoded, the message can then be sent using many different protocols, including HTTP or SMTP. Because SOAP messages are difficult to encode "by hand", software that wants to communicate using SOAP often uses libraries such as Node-Soap for Node.js to encode outgoing messages or to decode incoming messages.


A diagram showing the basic structure of a SOAP message. Image credit: http://www.service-architecture.com

A related protocol, WSDL, defines a standard to encode the technical description of a SOAP service, or set of SOAP services (called an "API"). A WSDL file contains information about the name, endpoint URL, arguments and return type for all SOAP services in an API. There are many tools for many different programming languages that allow you to automatically translate a WSDL into code that allows the direct calling of these web services.

REST: stands for "Representational State Transfer". REST is a large subject, but in practical terms, it refers to web services using HTTP protocol to communicate, with a very loose standard for data encoding. Unlike SOAP, you can send data in REST in virtually whatever format you want, either in the POST body of the HTTP message, or encoded into the URL being called as a query string. Of course, the service you are calling must understand the format you're sending the data in! This loose definition has led to certain data encoding standards being developed, the most prominent of which are JSON, XML and query string encoding (note that I'm not claiming that these were all developed as a response to REST)


Basic diagram showing REST flow. Image credit: https://www.chemaxon.com

REST services are often much easier to work with than SOAP messages, so they have mostly replaced SOAP as the standard web service protocol. There are many different types of REST messages, corresponding to the HTTP methods (GET, POST, PUT, DELETE, etc.) that these messages can be sent as. You can often "call" a REST GET service simply by entering that service's URL endpoint in a web browser's URL bar! The data returned from the service call will be displayed in your browser window, often encoded JSON or XML. Examples can be found here: for example, clicking this link (http://www.thomas-bayer.com/sqlrest/CUSTOMER/18/) will return information about a customer in this example database (in this case, customer #18, as defined by the "18" in the URL)


Why Is This Important?

As I've mentioned many times in this series, no software runs in isolation any longer. If you write software, you will be using web services in some way to communicate with other software. This is absolutely true for web development and nearly absolute for traditional desktop development.

The reason that web services are so ubiquitous is that they are also so useful - which is a reason in itself to know how to use them. We discussed above the ability of web services to retrieve data from remote sources - this is valuable in establishing a single source of truth for data, in keeping data private and secure, and in always providing the most up to date values when the data is retrieved.

Another functionality not discussed above are REST services which don't necessarily retrieve any data, but instead send a command to another system to perform some action. For example, a web service could allow our stock trading application mentioned above to submit a buy order on a remote trading platform. Without web service technology this would be impossible - and as your future work will almost certainly involve sending these commands over the internet, you'll need to know web services to do that as well.


Things You Should Know

I used a lot of complicated terminology and acroynms in this post. REST, SOAP, HTTP, XML, JSON, WSDL, and so on. This should indicate that web services are a full domain of their own, and my recommendation to you is to learn that domain. Learn how to use both SOAP and REST services, as these are the two most frequent service types you'll encounter. Don't just learn how to use these services, learn the underlying theory behind them - for example, learn how a REST GET message differs in use from a REST POST, and why, while you can use a GET to simulate a POST's functionality, you probably shouldn't.

Learning services is not as difficult as it sounds, and there are many online classes and books on the matter. I highly recommend you check out one of these and learn it, because this topic is currently a virtual requirement for employment as a software developer, and will soon become an absolute requirement - regardless of the language or system.


Hopefully this post has shown you just how important web services is. There is one more topic left in this series, and I consider it to be just as important as web services - that topic is securing your communications. In fact, if you don't know how to call web services securely, then you shouldn't be calling them at all. It's important! So check out some web service tutorials, and stay tuned for our final post in this series.