Martian Intuition

Here are the rough notes and PDF of my presentation to the Austin on Rails group last night.

Keynote PDF: Web Apps that Mesh

RESTful applications.

• What is REST?

  • a universal API
  • REST is a style of architecture
  • REST !== HTTP+XML
  • loose-coupling of interface to business logic
  • "REST requires a certain disconnect between the interface (which is REST-oriented) and the implementation (which is usually object-oriented)"
  • with HTTP, every request is already an operation on a URL-addressed resource
  • every resource has it's own URL
  • "Rethink your problem in terms of manipulations of addressable resources instead of method calls to a component."

• The HTTP request as a procedure call

  • URI == object (noun & adjectives)
  • HTTP method == action (verb)
  • one URI for RUD [of CRUD] operations on a single object
  • your API gets all the benefits of HTTP's ubiquity, age & existing tools:
    
    • URL's
    • stability (of the standard)
    • caching
    • proxying (load-balancing)
    • security filtering

• The Downside(?)

  • no asynchronous operations (HTTP has no callback support)
  • HTTP rides on TCP/IP, which makes timing unpredictable

• RESTful HTTP methods

  • create == POST - GET /people/new, then POST /people/create
    read == GET - GET /people/8 or GET /people/8;edit
    update == PUT - PUT /people/8
    delete == DELETE - DELETE /people/8
  • ";edit" is an alternate representation of the resource
  • ";complete" as in POST /people/8;complete
    may be used to commit a complex, multi-faceted transaction
  • many HTTP libs support these methods, such as Ruby's Net::HTTP
  • today's web browsers support only GET & POST
    • so for current end-users & backwards compatibility, we pollute the URI's with verbs
      update == PUT - POST /person/8?_method=PUT
      delete == DELETE - POST /person/8?_method=DELETE

• authentication

  • like all auth in Rails, it's up to you
  • HTTP is fundamentally stateless && REST is stateless
  • cookies [& therefore sessions] are stateful
    • require an authentication request to establish context [get a session cookie]
  • HTTP provides authentication headers
  • example: simple_http_auth plugin

• payload [data] format

  • there is no standard
  • keep it simple, and your app will benefit
  • Rails makes Hashes (ActiveRecords) and XML a two-way street:
    ActiveRecord#to_xml & ActiveRecord#from_xml (not core)
  • #to_xml is easy, but watch out for model changes that will change your API
  • REST is more than Rails; what about others that are not in our convention?
  • key is responding appropriately
    • Rails simplifies dynamic responses via ActionController#respond_to
    • instead of creating your own XML or text format, try a standard fit:
    • RSS (example: evolving lists & notifications)
    • JSON (example: client-side JavaScript manipulation)
    • YAML (example: human & machine friendly plain text)
    • XHTML micro formats (example: embedding data into the web interface)

Focus on the majority case: XHTML

XHTML can facilitate both human & machine use (tends to be more beautiful that way)

Making a better View

Theory

• find the wizardry in mark-up

• XHTML is more than a fad

  • XHTML is easier to understand; fewer exceptions to the rule
  • browsers render XHTML in Strict mode: easier styling
  • XHTML can be used as reliable, machine-readable data

• semantic mark-up: tags to express meaning, not just layout

  • visual display derives from HTML structure (now & forever)
  • simple and meaningful; universal logic

What is semantic? Mark-up that adds meaning.

"Meaning" is a relative term.

Can we have some standards for semantics?

Yes, thank you.

• Micro Formats

  • standards for semantic mark-up
  • right now it's geeky; bridge that gap
  • now|future developers may use your work in ways never planned
  • an open social networking mechanism
    • replace proprietary social sites; must reach critical mass
  • "XHTML provides a common language, and profiles such as XFN are common vocabularies."

• XHTML as a DRY datasource

  • loss-less for compatible data structures (hashes transform well)
  • make the mark-up work, THEN add client-side behaviors & style
    • most (any?) spiders won't run scripts, so don't hide your content in there
  • Ruby tools: REXML & Hpricot
  • example: site localization

Implementation

• "Piles of Partials" vs. "Monolithic Beasts"

  • "Many Blocks" vs. "A Big Rectangle"
  • structure partials according to model hierarchy of data
  • encapsulate partials with a CSS|XPath selectable parent div

• logical, predictable class & id's

  • empower the stylers & scripters
  • example tool: dom_id.rb

• "helpers" are actually View Helpers

  • get that code out of your template

• supporting themes

  • simple, semantic views make skinning a joy
  • example: theme_support_plugin