TWO TYPES OF STATE:1. application state - live on the client2. resource state - live on the server
Resource state stays on the server and is only sent to theclient in the form of representations.Application state stays on the client until it can be used tocreate, modify, or delete a resource. Then its sent to theserver as part of POST, PUT, or DELETE request, andbecomes resource state.RESTful service is "stateless" if the server never stores anyapplication state.
This is where the name "Representational State Transfer"comes from.
ETAGSETags are used to compare entities from thesame resource. By supplying an entity tagvalue in a conditional request header.
RESOURCE-ORIENTEDBASICSdifferent audienceeverything (interesting) thing represent as a resourcerepresentation of resourcesverbs, auxiliaries, complexity
THE GENERIC ROA PROCEDURE1. Figure out the data set2. Split the data set into resourcesFor each kind of resource:3. Name the resources with URIs4. Expose a subset of the uniform interface5. Design the representation(s) accepted from the client6. Design the representation(s) served to the client7. Integrate this resource into existing resources, using hypermedia linksand forms8. Consider the typical course of events: what’s supposed to happen?Standard control flows like the Atom Publishing Protocol can help.9. Consider error conditions: what might go wrong? Again, standard controlflows can help.
ADDRESSABILITYREPRESENTATIONS SHOULD BE ADDRESSABLE
Use commas when the order of the items matters, as itdoes in latitude and longitude: /earth/37.0,-95.2Use semicolons when the order doesn’t matter: /color-blends/red;blueWhen designing URIs, use path variables to separateelements of a hierarchy, or a path through a directed graph.Use query variables only to suggest arguments beingplugged into an algorithm, or when the other twotechniques fail.
REPRESENTATIONSRepresentations should be human-readable,but computer-oriented
SERVICE VERSIONINGEven a well-connected service might need tobe versioned
SECURITYHMAC"Authorization: AWS " + AWSAccessKeyId+ ":" +base64(hmac-sha1(VERB + "n" +CONTENT-MD5 + "n" +CONTENT-TYPE + "n" +DATE + "n" +CanonicalizedAmzHeaders + "n" +CanonicalizedResource))Authorization: AWS 44CF9590006BF252F707:jZNOcbfWmD/A/f3hSvVzXZjM2HU=
If all you want to pass around are atomicvalues or lists or hashes of atomic values,JSON has many of the advantages of XML: it’sstraightforwardly usable over the Internet,supports a wide variety of applications, it’seasy to write programs to process JSON, ithas few optional features, it’s human-legibleand reasonably clear, its design is formal andconcise, JSON documents are easy to create,and it uses Unicode.
XML deals remarkably well with the fullrichness of unstructured data. I’m not worriedabout the future of XML at all even if its deathis gleefully celebrated by a cadre of web APIdesigners.
I look forward to seeing what the JSON folksdo when they are asked to develop richerAPIs. When they want to exchange less wellstrucured data, will they shoehorn it intoJSON? I see occasional mentions of a schemalanguage for JSON, will other languagesfollow?
I predict there will come a day when someonewants to federate JSON data across severalapplication domains. I wonder, when theydiscover that the key "width" means differentthings to different constituencies, will theyinvent namespaces too?
JSON AND HYPERMEDIAHAL Media TypesHAL and LinksHAL and ResourcesHAL Embedded Resources
A status code simply isn’t enough information most of thetime. Yes, you want to define standard status codes so thatyour clients can perform reasonable branching, but you alsoneed a way to communicate details to the end-user, so thatthey can log the information for themselves, displayinformation to their own end-users, and/or report it back toyou so you can do something to resolve the situation.
SOURCESRESTful Web ServicesMicrosoft REST SpecAmazons HMAC-SHAHTTP Method DefinitionsJSON and REST presentationHAL Specification
THE ENDSławomir Chrobak /Link to presentation:@schrobakhttp://schrobak.github.io/slides/tgor