Master the Rest of REST to Supercharge Your Architectures
Get your arms fully around the work of genius that is Representational State Transfer, and apply this eminently potent theory to your current and future projects.
What You'll Learn about Semantic REST
- What Actually is REST, Anyway?
- Level-set with the origin and scope of this profoundly powerful architectural style.
- The Information Resource: Building Block and Load-Bearing Fiction
- See the Web—and other networked information systems—through a different lens.
- The Hypermedia Constraint
- Also known as HATEOAS. Learn what's so great about the worst acronym in existence.
- Data Semantics: The Missing Link(s)
- Apprehend the gaps that have been filled since REST was invented.
- Pipes With Types
- Master the other ultra-powerful feature of REST that doesn't get talked about.
- Cache Rules Everything Around Me
- REST takes caching seriously, and so should you.
- URI: User-Resource Interface
- Maximize the URI-as-UI pattern, and make websites that never
404. - Semantic REST and the Front End
- Unlock new capabilities for page composition, dispatching templates, styling, and client-side scripting.
Just about every Web developer has some idea what REST means—it's when you make your API respond to different HTTP methods. This isn't wrong, but it's missing most of the story. It's like the result of playing a game of Telephone, except with blog posts, and podcasts, and industry lore. In fact, no matter which API style you ultimately subscribe to, there's value in revisiting REST, because it's a much bigger idea than APIs—indeed a much bigger idea than the Web itself. Its inventor, Roy Fielding, calls REST an architectural style: a set of organizing principles that help you better think about designing networked information systems, where the Web is just one example.
This workshop is designed to get you past the two customary roadblocks to really getting REST into your bones. One, is that it's an entire PhD dissertation. Two, it was written in the dot-com 1.0 era, back in the days of Y2K. Why that second part matters is not because the contents are obsolete—in fact you'll be impressed at just how durable they are—but because a whole bunch of infrastructure that made the full vision of REST viable, hadn't been invented yet.
Note: This material is not hypothetical. These techniques are being used to govern the design of Intertwingler and Sense Atlas, and other projects besides.