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
- 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
- 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
- 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
- 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
- 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