RailsConf 2012 Notes

dhh.md

Progress

• Who doesn't like it?
• If we look back, we're not programming Cobol anymore, we're not no longer dealing with tons of boiler plate
• REST was not considered progress/good back in Rails 1.2
• Ruby 1.9. 1/3rd or so is still on Ruby 1.8. Some don't feel it's even worth it
• Bundler
• Asset Pipeline
• Progress that makes us uncomfortable are good. Pushes our limits. Everyone can say "Yes!", but do you really mean it? It doesn't always feel like progress at first.
• CoffeeScript
• "The old one was better"
• Being skeptical is OK, but you should be curious, not suspicious
• When does this happen?
  • Perhaps when you get burned by new Tech?
  • Client reacts badly "If it ain't broke, don't fix it! THIS CAN NEVER HAPPEN AGAIN"
• Perhaps we're mentally growing older
  • When we're young, no worries
  • The Open Source Community is like hippies
• Most Hippies don't stay hippies. Their curriosity got them lots of benefits. But now, they have something to lose.
• They become Mr.Mature

klabnik-apis.md

Steve Klabnik - Designing Hypermedia APIs http://steveklabnik.github.com/hypermedia-presentation/

• Started searching for the meaning of REST
• Like an indian journey
• Always like to be learning
• When people you respect/know are smart say something you don't know, or disagree with, make a mental note to learn more
• Happened with "Rails REST is not real REST"
• Decided to lean startup a book
• Put up an email form to see if people care
• Spent 8 months researching
• REST is over. (SUPER DEEP Portlandia reference)
• Can't just say "no YOUR WRONG"
• REST isn't a great term either
• When I say REST I mean 'Rails REST'
• Rails REST is a good default, but we can do better. (Progress!)
• REST Hypermedia APIs
• Big difference is links to other parts of content in your responses
• Hypermedia designs scale better, are more easily changed and promote decoupling and encapsulation, with all the benefits those things bring.
• We're good at saying things like "We love decompling. We love encapsulation." and then write 1000 line models.
• Current APIs have massive coupling between client/server.
• On the downside, it is not necessarily the most latency-tolerant design, and caches can get stale if you're not careful. It may not be as efficient on an individual request level as other designs.
• "REST is software design on the scale of decades: every details is intended to promote software longevity and independent evolution. Many of the constraints are directly opposed to short-term efficiency. Unfortunately, people are fairly good at short-term design, and usually awful at long-term design." _ Fielding
• People are good at thinking in short term not long term.
• Coupling is the enemy!
• "Webscale" is a thing. Google only encourages a few languages because they account for 8% of the traffic
• 1. Use HTTP Properly*
• 2. Use Hypermedia to Guide clients through business processes
• Why HTTP?
  • Fills all constraints except "hypermedia as the engine of application state"
• Use links, use HTTP correctly.
• "GET /photos/12/delete" is not using HTTP properly
• 5 steps of Hypermedia API design
  1. Evaluate business processes
  2. Create state machine
  3. Evaluate media types
  4. Create media types
  5. Implement!
• W3Clove.com crawls your site and validates all HTML
• JSON cannot drive your API. Custom format that uses JSON? Sure.
  • How do you do a link in JSON? There's no standard.
• Ideally you can use a type that already exist
  • Collection+JSON
  • HAL
• HTTP is a happy accident
• Fielding codified what was already around
• 2 things need to be considered when desining type:
  • data elements
  • hypermedia controls
• Custom type for w3clove: application/vnd.w3clove.validation+json
• +json means you can parse as JSON.
• Namespaced under vnd.w3clove.validation, but if other people made validations, then perhaps people could make application/validation+json
• Investigate how standards commities work
• { links: [ {"rel":"website-form", "href":"..."}, {"rel":"sitemap-form", "href":"..."}] }
• Examining your API as a statemachine is valuable by itself (if it takes 30 steps to do something, no wonder you're not making money)
• <Slides are over, lets talk about clients>
• Sample twitter client
• Only 1 URL is stored. DECOUPLING!
• Allows changing of how the client works by altering the API.
• Same model on client & server? NO, canonical source is server.
• Server driven, client just reacts