Style of software architecture commonly used to create networked services
REST comes from "representational state transfer"
Defined by Roy Fielding in 2000 as architecture for distributed hypermedia systems. Incidentally, NOT made for web services at all
---
marp: true
paginate: true
math: mathjax
theme: buutti
title: REST Architecture
---
Developed in parallel with HTTP1.1
# REST Architecture
While (almost) any application layer protocol can be used, REST APIs are almost always built on HTTP
<!-- headingDivider: 5 -->
<!-- class: invert -->
---
## REST - What it actually is?
Fielding's paper is available online at https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm and is relatively short
https://restfulapi.net/ seems like a good resource
Wikipedia is plain wrong, but less wrong in English than in Finnish
* Style of software architecture commonly used to create networked services
* REST comes from "representational state transfer"
* Defined by Roy Fielding in 2000 as architecture for distributed hypermedia systems. Incidentally, NOT made for web services at all
* Developed in parallel with HTTP1.1
* While (almost) any application layer protocol can be used, REST APIs are almost always built on HTTP
# REST architecture
## REST architecture
* Data and functionality are resources
* Resources are accessed through URIs
@ -26,14 +29,13 @@ Wikipedia is plain wrong, but less wrong in English than in Finnish
* Allows content to be accessed in a variety of formats (e.g. HTML, XML, plain text, image formats, JSON, etc.)
* Resource metadata is available to be used for detecting errors, negotiate the appropriate representation format, access control, control caching, etc.
* All resources are stateless
---
Access control: e.g. key token validation
<!--Access control: e.g. key token validation
Statelessness:
every response is isolated; fulfilling requests is not dependent on any other requests
client is responsible for sending the data about itself
client is responsible for sending the data about itself -->
# REST - Requirements
## REST requirements
* For something to be considered RESTful, it needs to follow a set of architectural constraints
* Be client-server
@ -42,7 +44,9 @@ client is responsible for sending the data about itself
* Have an uniform interface, with the restrictions
* Be designed to be a layered system (you don't need to know if you are targeting the end server directly, or something in-between)
# REST constraints - Client-Server
## REST constraints
### REST constraints - Client-Server
* First constraint is client-server
* Separation of concerns
@ -50,13 +54,8 @@ client is responsible for sending the data about itself
* Allows independent evolvement of components; no need to rebuild server if UI needs a rework, and vice versa
* Scalability by simplification of server components
* Portability of the user interface across platforms
---
Fielding's paper is available online at https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm and is relatively short
https://restfulapi.net/ seems like a good resource
Wikipedia is plain wrong, but less wrong in English than in Finnish
# REST constraints - Statelessness
### REST constraints - Statelessness
* Servers must be stateless
* Intended to improve visibility, reliability and scalability
@ -67,13 +66,8 @@ Wikipedia is plain wrong, but less wrong in English than in Finnish
* No need to manage resource usage across requests
* Server can quickly free resources for other requests
* Easily recover from partial errors
---
Fielding's paper is available online at https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm and is relatively short
https://restfulapi.net/ seems like a good resource
Wikipedia is plain wrong, but less wrong in English than in Finnish
# REST constraints - Cacheability
### REST constraints - Cacheability
* Client-cache-stateless-server
* Statelessness enables some endpoints to always produce the same result with the same request
@ -84,13 +78,8 @@ Wikipedia is plain wrong, but less wrong in English than in Finnish
* Trades reliability for performance, efficiency and scalability
* What happens when the data updates?
* At this point, we are at design rationale for the early (pre-1994) world wide web architecture
---
Fielding's paper is available online at https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm and is relatively short
https://restfulapi.net/ seems like a good resource
Wikipedia is plain wrong, but less wrong in English than in Finnish
# REST constraints - Uniform interface
### REST constraints - Uniform interface
* Central distinguishing feature of REST style
* REST implementations are restricted by four interface constraints
@ -101,13 +90,8 @@ Wikipedia is plain wrong, but less wrong in English than in Finnish
* Transfer information in standardised form rather than specific to application's needs
* Implementations are decoupled from the services they provide
* Encourage independent evolvement at the cost of efficiency
---
Fielding's paper is available online at https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm and is relatively short
https://restfulapi.net/ seems like a good resource
Wikipedia is plain wrong, but less wrong in English than in Finnish
# REST constraints - Layered system
### REST constraints - Layered system
* Allow architecture to be composed of hierarchical layers
* Last required constraint
@ -119,26 +103,18 @@ Wikipedia is plain wrong, but less wrong in English than in Finnish
* Hence bugs and errors in old code cannot be exploited, while still preserving functionality
* Enable load balancing
* Tradeoff here is added overhead and latency
---
Fielding's paper is available online at https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm and is relatively short
https://restfulapi.net/ seems like a good resource
Wikipedia is plain wrong, but less wrong in English than in Finnish
# REST constraints - Code-on-Demand
### REST constraints - Code-on-demand
* Optional final constraint
* Client functionality is allowed to be extended by downloading and executing code in the form of applications or scripts
* Goal is to simplify clients by reducing amount of pre-implemented features
* Is optional in REST because of reduced visibility
* Can be a problem from security viewpoint
---
Fielding's paper is available online at https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm and is relatively short
https://restfulapi.net/ seems like a good resource
Wikipedia is plain wrong, but less wrong in English than in Finnish
## REST elements
# REST elements - Resources
### REST elements - Resources
* Basic REST abstraction is a _resource_
* Any information that can be named
@ -147,13 +123,8 @@ Wikipedia is plain wrong, but less wrong in English than in Finnish
* Commonly URI
* Identifies resources interacting between components
* State of a resource at a certain timestamp is called a _resource representation_
---
Fielding's paper is available online at https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm and is relatively short
https://restfulapi.net/ seems like a good resource
Wikipedia is plain wrong, but less wrong in English than in Finnish
# REST elements - Representation
### REST elements - Representation
* Consist of data, metadata describing it and hypermedia links
* Hypermedia links help clients to transition to the next desired state
@ -163,23 +134,15 @@ Wikipedia is plain wrong, but less wrong in English than in Finnish
* Self-descriptive
* Client does not need to know if the resource is a book or an employee, it should act according to the media type associated with the resource
* Often leads to creating a lot of custom media types
---
Fielding's paper is available online at https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm and is relatively short
https://restfulapi.net/ seems like a good resource
Wikipedia is plain wrong, but less wrong in English than in Finnish
## RESTful APIs
# RESTful APIs
* Note that most "REST API"s out there do not fill these requirements
* Often any web API on top of HTTP is incorrectly described as "RESTful"
* Most commonly hypermedia isn't used as the engine of application state, or the application is not really stateless, and some people outright ignore those requirements from the get-go
* (which in case of both, technically makes the system RPC, not REST, but the name still sticks)
Note that most "REST API"s out there do not fill these requirements
Often any web API on top of HTTP is incorrectly described as "RESTful"
Most commonly hypermedia isn't used as the engine of application state, or the application is not really stateless, and some people outright ignore those requirements from the get go (which in case of both, technically makes the system RPC, not REST, but the name still sticks)
---
This slide sucks
## Yet more REST ramblings
* A REST API should be entered without prior knowledge beyond the initial URI and the appropriate media types
* i.e. media types expected to be understood by all clients that might use the API
@ -187,6 +150,10 @@ This slide sucks
* This is to keep interaction driven by in-band information
* REST does not equal HTTP
* As long as the REST constraints are honoured, the interface can be called RESTful
borb
4 weeks ago