Introduction

Overview

Welcome to REST fundamentals. The word REST has been thrown around quiet a bit over the last couple years with lots of service providers advertising that they have RESTful APIs and tool vendors pitching their latest frameworks as the tool for building RESTful services. However, when you take a look at what's being sold as REST and you compare it to what REST actually is, you start to see it disconnect, sometimes a pretty big disconnect. And so the purpose of this course is to step back from focusing on code and instead focus on how to design systems that meet the definition of REST.

Overview
- REST Drivers
- REST Properties
- Definition of REST
- REST and Other Technologies/ Architecture Styles
- REST and Richardson's Maturity Model 

Having a good understanding of RESTful design should then give you a better perspective when evaluating the myriad of technology choices that you need to consider when designing your own solutions.

This first module will focus on two things.

• First, will set this stage for understanding what kinds of problems REST was designed to solve. In that we'll consider a few key developments that are significantly impacting the requirements for a modern distributed architecture. We'll also take a look at the properties of a RESTful design that can help address these requirements. The primary goal is that you can make a determination right up front as to whether or not REST is something that is relevant for you.
• We'll then spend some time making sure that we have a definition for REST. Both what it is and what it isn't.

Subsequent modules, we'll dive more deeply into the different aspects. But here, we'll provide the starting point, as well as compare REST to a few other technologies and approaches such as HTTP, URL, SOAP and remote procedure calls or RPC.

Finally, we'll examine an approach for categorizing applications based on the different architectural characteristics that they exhibit where each progression is moving closer to a restful architecture. This model has more recently become a popular tool for understanding REST and has been sited in several notable books and blogs. So the goal of this module is that if you don't watch any of the other modules in this course, you'll at least be able to come away with an understanding of what REST is and whether it might be a good fit for you. So let's get going.

The Need for REST

We'll start out by taking a look at some of the key drivers that can introduce real challenges for a modern distributed application.

REST Drivers
 - Heterogeneous Interoperability
 - Devices
 - The Cloud

The first is heterogenous interoperability which is really just a fancy way of saying, "I want to integrate applications that are built against different frameworks and run on different platforms." We then have the rise of devices and finally the move towards the cloud.

Heterogenous Interoperability

Heterogenous interoperability can be illustrated by taking a look at an article on any popular news site. When you first examine the web page, you'll find lots of different elements on the page that perform various functions.

Everything from site search to sharing the article be a different social networks. In this distributed service-based architecture, the different providers of functionality cannot make any kind of assumptions about the platform that each other is running on and yet this kind of broad integration is only possible if the way in which the different pieces interact with one another is simple, consistent and reliable.

One of the things that we'll see as we look more at REST is that it's based on this idea of a network-based API rather than a library-based API and this approach makes it a good fit for integrating heterogenous applications.

Devices

Now, let's extend our news web site example so that it supports multiple devices. It's important to note here that device now goes far beyond simply phones and tablets. For example, you can see that I've included an in-dash navigation system in the illustration here. In this case, the device might want to integrate with our news application so that it can pull down traffic related content based on its GPS coordinates or perhaps it even has the capability of reading a news article to the driver based on the article's text.

In any case, it's likely that many if not all of these devices will serve to only exacerbate that problem of heterogenous interoperability. However, they also add a new set of problems. First, many devices provide their user experience via natively run applications rather than through mobile web applications.

These are deployed at different times from one another and at different times from the services that they consume. As such, the services and client applications all need to be able to evolve independently from one another without running the risk of making one another unstable.

Next, efficiency and performance are big consideration for devices where the overall network is inconsistent and unreliable and more importantly where many users pay data charges in proportion to the amount of bandwidth that they consume.

Now, the previous two drivers of heterogenous interoperability and the rise of devices both illustrate the challenges inherent in building an application that derives its capabilities from the capabilities of lots of other different providers and one that makes its capabilities available to lots of different types of consumers.

However, what about the sheer number of consumers? For many businesses, the cloud represents an opportunity to take advantage of something called elastic infrastructure which is both computing capability and storage capacity that grows and shrinks with the application or applications that run on it.

This can address a number of problems. For example, a service provider is less likely to run into a situation or a sudden rise in the popularity of a service overruns the overall capacity of the infrastructure. With the notion of elasticity is also this idea that you only need to pay for the infrastructure resources that you actually use. So the idea is that you're able to minimize the risk of having spent money on unused capacity.

With regard to scale, the cloud is not a cure-all that will magically scale all applications infinitely and cheaply. As one article puts it, cloud computing is extremely powerful because when done right, it can provide great financial rewards as well as operational rewards but understand that the hardware layer alone is merely a tiny piece of the puzzle or to put it another way, it is critical to build a scalable architecture in order to take advantage of a scalable infrastructure. As such, applications that run in the cloud need to be architected in such a way that they work efficiently both with the elastic infrastructure of cloud providers and the larger infrastructure of the networks over which they communicate.

Now, while scale is certainly important to some companies, many companies see the primary value of the cloud differently. Specifically, the value is in moving to this pristine idealized data center shown on the right from the data center that you have to manage day in and day out, you know, that data center that draws copious amounts of power requires its own air-conditioning unit to keep cool is the source of regular 2 a.m. pages because a hard drive failed and one that will overtime need to be continuously upgraded and actively managed.

In reality, that ideal data center probably looked similar to the one that you have to manage. But by shifting that burden to a cloud provider, to you, it can look like whatever you want it to and that is the big idea. For companies trying to achieve this idealized data center, there are couple ways in which software architecture can help significantly.

First, the system should be designed such that it does not depend on complicated middleware which requires constant configuration changes and management overhead and which is historically had some scale limitations of its own.

Secondly, the system should b designed with transparency in mind so that failure conditions which despite the best architecture will still happen. When failures occur, they can be quickly diagnosed and corrected.

Architectural Properties

Now that we've established some of the challenges that exist in designing modern distributed applications, let's take a look at some of the properties of a RESTful architecture. In the upcoming modules, we'll get in to how these properties are actually achieved in a design but for now, we'll look at the properties themselves and see how they line up to the challenges that we just discussed.

Properties of REST
- Heterogeny
- Scalability
- Evolvability
- Visibility
- Reliability
- Efficiency
- Performance
- Manageability

The first property of a RESTful design is heterogony. This has a definition consistent with the business driver mentioned earlier. It's the ability of the application to see mostly interoperate with other participants regardless of language or platform.

Next we have scalability. REST addresses scalability in a couple different ways. First, it limits the amount of complexity that can exist between components in a distributed system enabling the complexity of the overall system to scale much past the limits of a more typical application architecture. Second, REST enables an application to more efficiently manage requests and to scale out horizontally when needed.

Next is evolvability. Evolvability describes the ability of RESTful clients and services to evolve independently of one another as was described earlier when we were talking about the challenges brought about by devices.

Visibility can provide significant benefits and that it enables value-added components such as monitoring applications or intelligent gateways to operate correctly without meeting access to any hidden and potentially proprietary state. A good example of that is session state.

Improved visibility or reliability also means that a client can more reliably recover from failures including partial failures and REST enables you to develop rich compensation strategies for those cases.

As I mentioned with scalability, a RESTful architecture enables multiple components such as proxy servers and caches to participate in the handling of requests. These intermediaries have the effect of taking load away from your server. Additionally, a RESTful design keeps your server from having to manage a bunch of shared state and therefore it enables it to manage its own resources more efficiently.

And with performance in the same way that caches can improve the efficiency of a RESTful application, they can also greatly improve the speed in which a response can be delivered to a user agent. Thereby improving the overall perceived performance of your application.

And finally, and this is based in large part on visibility, a RESTful application can be more easily managed because the interactions between components happen in a highly consistent and highly visible way and therefore management tools can have a much greater impact.

In looking at how all of these properties mapped to heterogenous interoperability the rise of devices and the cloud, you can see that all of these properties are important to at least one of these areas if not all of them. So hopefully, by now, I've convinced you that this REST thing is something worth taking a look at. So then, what is it?

Defining REST

Well, let's start out by looking at what it's not and possibly clear up a few common misconceptions.

What REST is NOT
- RPC
 -- REST is not a way to call methods over a network without the overhead of SOAP and WSDL
- HTTP
 -- While most current RESTful systems are built using HTTP, an architecture implemented on top of HTTP is not inherently RESTful
- URI
 -- Largely because of the frameworks on which they are built, many RESTful systems have clean URLs("cool URLs"). However this is not a requirement for REST
 -- Hyper-focus on URIs can actually make design non-RESTful.

First, REST is definitely not a new way to use HTTP to make remote procedure calls or RPC. This goes straight to the heart of a common misperception that REST is inherently any architecture that is not SOAP. Now, at the end of the day, the mechanics will probably end up with a function somewhere getting called on a server somewhere. But that's not what I mean when I talk about RPC. In RPC, the design target of a network interaction is a remote function or a method. And the goal of an RPC architecture is to abstract a way all of the other details of the network so that while components may be interacting over a network, those details are completely abstracted away from the developer who's writing the code.

In REST, the design target of a network interaction is a resource which is something we'll talk about at greater length later on and the semantics around the remote interaction are not abstracted away at all. In fact, they're made of key part of the design.

Second, REST is not HTTP. This may seem like an odd statement since HTTP is the protocol over which most RESTful interactions happen. However, it's important to make the distinction because it's not that difficult, and because of that many people do this, it's not that difficult to write an HTTP friendly application which is fundamentally not RESTful. For example, a service that makes great use of HTTP verbs does not automatically qualify as a RESTful service.

Finally, REST is not URIs. I think that the over association came about because of some really great frameworks like Rails and MVC which made it really easy to design and manage the URL space with routing. Unfortunately, one side effect of this is that many people I talk to, spend a tremendous amount of energy and angst trying to figure out how to carve out the perfect URL space when designing a RESTful service and we'll see in future modules that URLs have their place in REST, however, they don't paint the whole picture and starting with URLs makes it very easy to slip back in to an RPC way of thinking about your design.

So having named a few things that REST isn't, let's take a quick look at what it is. In short, REST is all about style. It's not a protocol. It's not a specific implementation design pattern. It's a style of thinking about and designing your applications. A quick bit of history, it was first introduced by a guy named Roy Fielding and his doctoral dissertation in the year 2000. However, Fielding had been working on the web and on REST for nearly seven years prior to his dissertation being published. Fielding was one of the original developers behind the World Wide Web working on HTTP and the URI specifications and he developed REST as a way to describe the larger architectural concepts behind how the web was designed to work. As Fielding says in his dissertation, the phrase representational state transfer is meant to evoke an image of how a well-designed web application behaves as a virtual state machine of web pages where progress is made via links.

REST by Comparison

Now, as I mentioned earlier, many people define REST as simply something that isn't SOAP. This isn't terribly accurate as REST is an architectural style and SOAP is more of an implementation detail. Why does this matter? Are there RESTful SOAP applications out there? Certainly, none that I'm aware of.

REST and SOAP
- Many people think of REST as "something that isn't SOAP"
- SOAP (and WSDL) is an implementation detail for RPC-style system

- REST is juxtaposed with RPC

SOAP naturally aligns itself with an RPC design style. It's important to call out the incorrect association though because believing that REST is simply something that is not SOAP can get in the way of understanding more fully what REST actually is and that is after all the point of this course.

So now that we've gotten that little point of clarification out of the way, how do REST and RPC compare? The table here illustrates a few ways in which these architectural styles differ pretty dramatically from one another.

RPC
 1. Contract is a service and its operations
 2. Action semantics are specified out of band
 3. Error semantic are specified out of band
 4. Limited caching support
 5. Client and server share ownership of the URL namespace
 6. Inputs and outputs are tied to underlying runtime types
 7. Can tunnel through multiple protocols

REST
 1. Contract is the uniform interface
 2. Actions semantics are specified by the uniform interface 
    and state transition are specified by hypermedia controls
    embedded in representations.
 3. Caching supported by all intermediaries which understand the
    uniform interface
 4. Server owns the URL namespace
 5. Inputs and outputs are tied to the media type specification
 6. Tied to the uniform interface of supporting protocol

First and probably most importantly, the whole idea of a contract that thing, that forms the language of how a client and server understand each other is fundamentally different between RPC and REST. In RPC, as the acronym would suggest, the contract is the service and its procedures. In REST, the notion of a contract aligns to something known as the uniform interphase, more on that later.

Next, the definitions of available actions are specified out of band in RPC many times using something like a service description file as in the case of SOAP services. In REST, those actions are standardized by the uniform interphase and progress through a workflow is made by something called hyper media. Again, we'll spend much more time in a later module on this concept.

Just like with procedures, the set of all possible errors for a procedure are also specified out of band with an RPC design. In the case of REST, error semantics are part of the uniform interface.

And while you can build RPC applications that take advantage of caching, this is not something that's guaranteed by the RPC style whereas it is in the case of REST by way of the commonly understood uniform interphase.

In RPC, procedures are generally called by way of the client knowing the URL for a particular service or operation. As a result, once the client has been deployed, the server can rarely and if so painfully change the URL structure for its services. In REST, the server owns all of its URLs with the exception of a single entry point URL. And clients access individual services by following links.

RPC is based around procedures and procedures have parameters. As a result, an RPC application will almost always expose some notion of a type system. Sometimes it's a platform neutral type system as in the case of access D. But there's almost always one there. REST does not have notions of procedures with parameters, only the idea of media types and media type specifications. As such, there's not a formal type system that you have to adhere to.

Finally, one benefit of RPC, and particularly of some RPC frameworks like WCF is that because there are effectively self-contained and how they define application semantics it means that they can tunnel through lots of different protocols, usually with a simple configuration switch. This is why frameworks like WCF can run on top of protocols like HTTP, TCP and MSMQ without having to change any of the actual service code. A RESTful system is tied to the uniform interface of the supporting protocol which right now is typically HTTP.

Now I just said a minute ago that REST is not HTTP. However, HTTP really is the protocol on which most RESTful systems are built. HTTP provides a simple uniform interphase on which the constraints that define REST depend. And this really isn't a coincidence. Notice the authors of these two documents,

• https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf
• https://www.w3.org/Protocols/rfc2616/rfc2616.html look familiar?

Demo: Richardson's Maturity Model

The last thing I want to mention in this module is the visual that you can see here called Richardson's Maturity Model.

This way of looking at system architecture has gotten some attention recently with books like REST in Practice and through authors like Martin Fowler and for good reason. It's a really helpful tool for seeing where a given architecture fits within the scope of all the concepts that we're going to be talking about here in this course.

• The path towards REST was described by Leonard Richardson and has been referenced in quite a few books and blog
• Only Level 3 in this model can be actually considered REST (what-is-the-richardson-maturity-model)

From a maturity standpoint, an application starts at level 0 as a set of a plain old XML or POX services and moves up the stack by adapting more RESTful characteristics until it last it becomes RESTful. One reason I also want to mention this model is because there's been some confusion around what the different levels represent with respect to REST. To be clear, level 0 through 3 here represent incremental steps towards REST. They do not represent different levels of rest. Only in applying hypermedia to your application design, as you can see at level 3, can your design be considered RESTful.

Summary

So let's recap. In this module, we've covered some of the reasons why REST might be advantageous for you to consider in your designs.

We've examined some of the properties that a RESTful architecture should produce and we've mapped the back to some of the challenges that new trends and technology are bringing to bear. We then spent some time providing a basic definition for REST as well as identifying what it isn't and then juxtaposing it with some commonly associated architectural styles and technologies.

My hope is that at this point, we have a clearer picture of whether a RESTful design style is a good fit for your particular scenarios. In the next module, we're going to see how the definition of REST is formed through the application of architectural constraints. We'll explore those constraints in more detail and see how they yield the properties that we summarized here in this module.