[SOUND] Hi. My name is Gregory Gunderson, and I'm a researcher and software developer in the Ma'ayan lab. Today, I'm going to talk about Accessing and Serving Data through RESTful APIs. This lecture will be fairly technical, and will not directly pertain to systems biology, but knowing how to use APIs to access data is critical to both data science generally and to biomedical research. Of course sometimes sharing data is manual like putting it on a flash drive and then walking it over to a colleague. Or you may share data by emailing someone a file. Or perhaps most often, data is shared online. Not through downloadable files but through web services that let you programmatically access the data. These services are called APIs, their architectural model is called REST, and they're implemented with HTTP. We'll cover these important concepts so that you can access and serve data online. Here's an outline of what we're going to cover today. First, we'll talk about REST. As I mentioned on previous slide, REST is an architectural model for web services. Throughout the lecture I'll stress that REST is just an idea, it's just a description. Next, we'll talk about APIs. An API is an interface for a program, in this case, a web service. An API can be RESTful meaning that it adheres to the REST model. We'll talk about what that means exactly in a bit. And, finally, we'll talk about HTTP, which is the communication protocol used by the worldwide web and an implementation of the REST model. Okay, let's talk about REST. REST stands for Representational State Transfer. That's a mouthful, so let's break it down. First, State is all the stored data of a program at an instant in time. I think of State as a snapshot of a program. What would you get if you froze a program during a middle of it's execution? Representation is a relationship that expresses the similarities between objects. For example, the capital letter I and the word unit are two different representations for the same number, number one. And Transfer refers to the fact that we're passing this representational state around. In this case we have a client and a server. The server has the data and the client request the data. In the world wide web the client program's typically your web browser. So putting this all together, REST is a model in which a client and a server interact through representations of the state of the server. There's a lot on that last slide, so let's review with an analogy. In this analogy the computer program is a sunflower, it's a real living plant, it grows and changes over time. It's not on this slide. And the state is a frozen moment in time in the life of the sunflower, the image on the left. Now, a representation is something like a Polaroid picture of the sunflower. It's not the real flower, and it's not even the flower frozen in time. Another way of understanding this is to observe that there are many other possible representations. For example, a painting of a sunflower would also be a representation. Finally, if you hand someone a Polaroid picture of a sunflower, you aren't giving them the flower. You're giving them a representation of it at a moment in time. If you wanted to know how the sunflower was doing two weeks later, you would have to request another Polaroid picture. Finally, let's talk about some more specific properties of the REST model. First, the REST model specifies in client server architecture. Clients care about the user interface and user state, servers care about the data. As we just saw a client request snapshots or tiny slices of the data from the server as needed. Have you ever noticed that you can access any web application from any device that has a web browser? This is possible because of the client-server architecture. Second, client-server interactions are stateless. What this mean is that no interaction is dependent on a previous or future interaction. For example, have you ever noticed that you never have to install updates for web application. That's because your client has no persistent state. It just rerequest all of the relevant data every time you visit. Next, REST applications can be layered. The only contract is the client request and the server responds. The client doesn't really know or care how it happens. For example, if you open your web browser and navigate to www.google.com you have no idea where the response is really coming from. For me perhaps the server is in New Jersey. But if you access the same site from India, I can guarantee you that the response is coming from a server much closer to you to increase performance. And finally, REST resources are cacheable. If the server is sure that a resource will not change, it can instruct the client to store it for some amount of time. I suppose you could argue that this is the client holding some persistent data, but it's important to remember that the server has total control. The server can say to never cache or to stop caching. Before we go on, I want to point out why REST is the next model. You interact with RESTful applications every single day. For example, if you use Facebook on your smart phone and then later use Facebook on your laptop. You're accessing the same underlying data but through multiple interfaces and tools. If you click the refresh button, you might see new data. If you log in as another user User, you would see different data. In other words, we're separating the real state of the data from the way it's represented and how you interact with it. This is a very powerful idea and is at the heart of why the world wide web works. This slide is pretty self-explanatory. Any application, web service, or API that adheres to the REST's constraints to the REST model, is called RESTful. Let's look at an example of a RESTful web service. We'll be using www.thomas-bayer.com/sqlrest. You can follow along if you'd like. Before we begin, notice the description. Following the XLink attributes, you can navigate from resource to resource. Just copy the links and paste them into the address field in your browser. This description is simple because part of the ambition for a RESTful web service is that things are self-explanatory. In every response you get everything you need. We'll see what that means. First, let's click on the link. My web browser is the client and www.thomas-bayer.com is the server. I ask for a resource not caring how many layers it takes to get there. And returned this representation of some data on the server. Notice, it looks like there is a customer list, an invoice list, an item list and a product list. Let's say following the links, say, customer list. It's just the base URL so far, plus the word customer. As you see, I'm returned a list of customers and each customer has a X-link. Finally, let's pick a particular customer, say, number nine. The resources located in the current URL plus /9. Really, the URL could be anything since we're given the links but it's nice the developer was consistent. Here we get information about someone named James Snyder. So that's it. That's a RESTful web service. Did you notice that we did not have to know anything about the application, about the state of the program, or about the resources' actual locations? All we needed was the base URL. Every request responds to the statements I.E. not dependent from the previous response. [MUSIC]
