Doing Rest Right - Scott Raymond - Firewheel Design

• notes
  • orthodoxy & orthopraxy
    • "doing it right"
    • what REST  Isn't
      • pretty URLs
        • GET http://eg.com/users?id=123 - nothing unrestful about this
      • CRUD
      • respond_to
      • map.resources
      • HTTP
      • a protocol
      • an architecture
    • So What is REST?
      • the architectural style of the web - different than 'an architecture'
      • more "guidelines" than rules
    • IDENTIFICATION
      • ADDRESS
        • 'my name is URL.'
          • note: took photo
    • INTERACTION
      • Is it safe?! Is it idempotent?!
        • "get" is safe - maybe increase stack count
          • not going to blow some missle up
        • "post" neither safe or idempotent
      • THE UNIVERSE INTERFACE
    • CONTENT
      • DATA
• What's a Resource?
  • "the weather in portland today" is a resource
    • "dynamic" is different tomorrow
• Questions
  • How can I update several resources at once?
    • Classic Example: To do list
      • Scoping
    • Create on the client side, a url - some kind of name: that would live for that set of resources
      • e.g some query string
      • created a new resource, that represents those 5 resources
  • How can I do partial updates?
    • Person Resource on the web
      • just change the persons name - nothing else
        • How do I do that?
          • update via a url /people/1/first_name
            • effectively updating one part of something
  • How should I do authentication?
    • "cookies - frowned upon by rest purists"
      • "often abused"
      • undesireable dependence
    • "The Right Answer"
      • use something like http basic authentication
        • obvious down sides, UI for http basic is always hideous
          • "password being transmitted in the clear" not good
      • "Still use cookies, but use them in such a way that each request is self-sufficient"
        • Rails is doing it the right way. Rails stores session data in the cookie itself, not on the server.
  • Should I include Content-type info in the URL?
    • shouldn't be in urls
      • should be in http request headers
      • downside: can't link to a specific representation
      • if a person is a visual representioatn and pdf
        • you can't link to one or the other, just one way to get it
          • bad
    • design your urls properly
      • don't blindly accept the "rails way" for urls, or anything for that matter
  • What about reliability?
    • still possible to make post a reliable operation
      • divide post in two
        • post first to a factory method, that returns a newly minted url
  • What about transactions?
    • deduct something from bobs account - add something to marry's account?
      • scoping issue
      • solution
        • come up with a name of the transaction
          • post or put to that
  • What about concurrency?
    • if client a, and client b change a resource (at the same time) which one wins?
      • need some kind of locking mechanism "etags"
      • opaque tocken to reprsent the current status of the resource
        • "server can tell it's updating from a stale resource and throw a 500 or something"
  • I need more than one representation with the same media type.
    • two html representation's of the same resource
    • create your own media type
  • How do I handle asynchronous operations, like notifications?
• I'm speical; I need more than GET/POST/PUT/DELETE semantics.
  • You're wrong.
  • You can model anything in REST
    • May not be the best / ideal - but it works and is good
    • Lots of advantages to the rest approach
  • Uniform Interface
    • Suffiecient in general