Web services are a central part of modern software architecture. In the early days of the World Wide Web, web browsers living on client computers were designed to help users find Internet resources. You might be reading a document, you'd see a link to another a document, you'd click the link and boom. The next article would appear. The early web was all about hyper text, the H in HTML. It's fun to use the way back machine, a huge archive of past web content to look at some early web pages.
For example, the first website in the United States was housed at the Stanford Linear Accelerator Center in Palo Alto, California. You can see early versions of their web site using the way back machine by going to www.slac, that's slac.stanford.edu. That will take you to a listing of all the different versions of the website that are available in the way back machine. I'll start with the earliest version of this website that's available in the way back machine archive.
It's from 1996. I'll click on it. And that takes me to the archived website. This website was designed for scientists. You could go into any of the links and from there jump from document, to document, to document. There wasn't much fancy about it but it made information available at a blinding speed. Now, compare that to the modern version of the same website at www.slac.stanford.edu.
And XML to retrieve data from a server without having completely refresh the webpage. And on the server, web services respond to web requests with data that was sent in forms not intended for direct human consumption. Modern web applications such as web based email clients like Google's gmail, Microsoft's Outlook.com or Yahoo! Mail all do this. But to avoid refreshing a page while getting new data, you need a way of communicating over the web that goes beyond visual content and web services fit the bill.
Web services typically have very strict requirements for usage that are documented for developers. Modern web service communications are nearly always handled over HTTP. That's hypertext transfer protocol. But the format of the message that are being sent and received can differ greatly. If you're a software developer and you want to use a web service, you'll need to know the application programming interface or API for that service. Here's some of the critical things you need to know.
Is the web service secured? And if so, what do you need for authentication? Are a simple user name and password sufficient? Or does some sort of security token get passed back and forth? And when data is returned from the web service what form will it be in? Would it be in XML, JSON or some other format? Are there particular field names and data types that you need to know about? And are you always getting back all of the data or is there some sort of data paging mechanism? All of these taken together are the web services API.
For developers the idea of an API is commonplace, whether it's a client-side library for a particular language, such as Java, Ruby or Python. Or a description of how to perform actions on and get data from a remote server. An API and its associated documentation are critical to the developers success. As you will see throughout this course, you can only use web services if you know how to speak their language. And finally, there's a big difference between knowing how to talk to a web service and knowing how it's working in the server environment.
When you send a request to the web service you'll need to know whether to use SOAP or JSON. HTTP PUT or GET request and so on. But you usually don't need to know what programming language, database or other technologies are being used in the server environment. A web service hides its complexity behind the wall of the web. It doesn't matter whether the web service is managed by PHP, ASP.net or Node.js. As long as you send the request in the right format and get back the expected responses, you'll be able to call the web service from your client-side application.
And if you're building web services you shouldn't have to care what sort of clients are sending the requests. They could be coming from desktop, web, mobile or embedded applications. They could be running on a computer, a phone, a tablet or an Internet connected refrigerator. And, of course, they can be coded in any supported programming language. As long as they ask their questions correctly, your web service should be able to send back the expected responses.
Web services are therefore, the great decouplers of modern computing. The client doesn't understand how the server works and vice versa. Each does what it does well. And they work together through a shared vocabulary.
- What is a web service?
- Understanding the available transfer protocols and message formats
- Examining SOAP request and response formats
- Creating a simple SOAP service in ASP.NET
- Choosing a SOAP implementation
- Associating REST actions with HTTP requests
- Sending RESTful requests
- Creating OData request URIs
- Securing web services