REST
Table of Contents
1 REST center
Representational State Transfer
2 Good news, everyone! two_col
- You already know REST
- Representations
- State
- Transfer
2.1 Definitions notes
- Representations
- concrete version (bytes) of a resource
- State
- The status of a representation (bank account)
- Transfer
- HTTP
3 History two_col
- Roy Fielding co-wrote HTTP specs
- Defined REST in his 2000 PhD dissertation
- Defined core set of constraints and why they were important
3.1 Relation to HTTP notes
- HTTP/1.0 1996
- HTTP/1.1 1999
- ReST defined in thesis 2000
- REST was designed as the principles of HTTP
- HTTP came out of and embodies these principles
- But HTTP is not REST!
4 Constraints
- Client-server
- Two separate systems talk to each other through a well defined interface
- Stateless
- No context is stored between requests
- Cacheable
- Clients or intermediaries can cache results, and requests and results can specify caching information
- Layered
- Requests can go through intermediaries (proxies)
- Uniform Interface
- The protocol between client and server follows the same rules regardless of the specific application
- (no term)
- Code Transfer (Optional):: Servers may send code to clients to execute
4.1 Describes the Web notes
- Browsers, webservers
- HTTP is stateless
- We have caching layers, CDNs (in another lecture)
- Proxies, both front end backend (another lecture)
- HTTP is uniform if you're getting a page from your portfolio or a CSS file from NYT
4.2 Client-Server two_col
- Browsers don't care what webserver is providing representations, or what database is holding data
- Servers don't care which clients are connecting
- Overhead of transferring data
- Fewer, simpler failure modes
4.3 Flexibility notes
- Theme of many of these constraints
- We are trading off flexibility for performance
4.4 Stateless two_col
- Simplifies server design and storage
- Simplifies request grammar
- Improves scalability, error recovery
- Overhead of transferring client state
- Not convenient for interactivity at protocol level
4.4.1 Grammar notes
- Must cover all possible states, eg. in a directory that is deleted
4.5 Cacheable two_col
- Browsers can store CSS and JavaScript
- Businesses can cache responses, even from external sites
- Servers can specify how long things should be cached for
- Cache invalidation is hard
- Can't rely on updated resources updating "everywhere"
4.5.1 Consistency is hard anyway notes
- Cache invalidation is hard, but alternative is basically not feasible
- Can't update mobile phones in "real time" when they are disconnected
4.6 Layered two_col
- Apache webserver is an intermediary to
app.py, but the browser doesn't know! - Allows "one" hostname to be served by hundreds of '
app.py' servers - Can also separate caching, or authentication and authorization
- Can't rely on server specific details - our request could be passed along to anyone
- Server identification more difficult - "Man in the Middle" attacks
4.6.1 Man in the Middle notes
- Where an adversary intercepts your requests and returns back potentially altered results
4.7 Uniform Interface two_col
- Client and server know how to interact regardless of application hosted
- Yelp uses same interface as Twitter
- Wider variety of clients that can handle multiple applications
- For really unique applications, must jam into old paradigms
- Difficult to optimize for performance of single application
4.7.1 Clients notes
- Imagine using a different application for Yelp and Twitter: one has no
back button, other can't select text, etc…
- Actually don't have to imagine too hard, just use your phone
- Difficult to think about what a "resource" is for search
4.8 Code on Demand two_col
- Server sends code to execute on client
- JavaScript, Java, Flash, VisualBasic
- Can allow interaction without rebuilding representation
- Difficult to ensure code safety and isolation
- Sandboxing limits performance and flexibility
4.8.1 Sandbox notes
- An area for a program to run that won't let it do real damage
- Prevent a virus from reading your personal finances
- But this means can't allow the program to helpfully read data
5 REST is not HTTP two_col
- Other protocols are "RESTful"
- Waka is Roy Fielding's next protocol
- SPDY lowers latency of HTTP-style requests
- Must embrace REST constraints
5.1 New Protocols? notes
- If you want to make it RESTful, try following Fielding advice
- Worked pretty well for the Web
6 Web is RESTful
- Web is build on these ideas
- Better leverage attained by embracing REST
- Flexibility, scalability, visibility, simplicity
7 How to Spot RESTfulness
- Should think through constraints, but here are some heuristics
7.1 Uses HTTP
- HTTP can be a Uniform Interface
- vs. FTP not RESTful
7.2 Uses HTTP commands
GETPOSTPUT…- vs. Uses POST for everything
7.3 Uses HTTP return codes
404200- vs. always responses with
200but has an error message
7.4 URLs point to resources
/api/users/jblomo/api/classes/i253- vs. URLs point to commands
/api/command/api/user/api/getClasses/
7.4.1 /api/user notes
- Where
/api/userthen only takesPOSTcommands with auser=jblomoargument - Fielding called this "Identification of resources"
7.5 Representation links
- A representation links to new possible actions
- Client only needs to have representation
- Hypermedia as the engine of application state (HATEOAS)
7.5.1 HATEOAS notes
- HTTP contains links to the next action: the business you want to view, or forms with actions for the review you want to submit
- You don't need to memorize the prefix of businesses, then type in an ID
- Contains the full URL link
7.6 Example
{"business": "http://yelp.com/biz/27",
"user": "http://yelp.com/user/5"
"review_text": "..."}
7.6.1 Trade-offs notes
- Can easily follow links without known a priori structure
- Only need "entry" URL to start using API/website
7.7 Counter Example
{"business_id": 27,
"user_id": 5
"review_text": "..."}
url.open("http://yelp.com/biz/" + business_id)
7.7.1 Trade-offs notes
- Less data transfered
- Got back just a simple ID… what do we do with it?
- Some APIs require you to read the documentation, then hard code the path and stick the ID you got in the response in
- Note HATEOAS: Instead should receive the whole URL in this response
7.8 Uses Headers for Metadata
Content-TypeXML or JSON- vs. response has extra metadata in XML
7.8.1 SOAP notes
- For example SOAP has a
<soap:Header>section - Self-descriptive: client can figure out how to parse from the message content, not some external source
8 A place for the RESTless
- Communicating over many protocols
- Performance critical
- Prototypes