State Machines to State of the Art

  • 5,084 views
Uploaded on

Smart efficient design using REST and MVC. …

Smart efficient design using REST and MVC.

Web applications are everywhere now, but many of them misuse the basic concepts laid down by the HTTP protocol, miss the benefits of making the application and the API the same thing, and don't set themselves up to grow if things take off.

This talk will look at the design decisions you need to make to ensure that your application really is ReST-ful, how we fit that cleanly into MVC, and how state machines can help us manage clean state changes in a stateless protocol. The talk will go into some of the available design patterns with class diagrams and code snippets showing how and where to implement them.

Originally presented at PHP UK 2009.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • Computer Science in general solved these problems quite a while ago, that's the point. This talk illustrates some of the things web developers often forget about the protocol they use and as a result make their lives more complicated. J2EE provides implementations of these patterns, but also still provides enough leeway for developers to do it wrong.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
5,084
On Slideshare
0
From Embeds
0
Number of Embeds
11

Actions

Shares
Downloads
43
Comments
1
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Today I'm going to be talking about how we go about designing web applications and some of the tools we can use to make those designs simple, robust, modular, and hopefully somewhat future-proof. A little about me, I'm a lead developer at Plusnet which is a BT-owned ISP up in Sheffield. People sometimes seem surprised that an ISP needs a dev. dept when presumably all we need to do is plug a few wires in and flick a few switches in an exchange. The difference is that we focus on automating as much of the entire process as possible: signing up, provisioning, billing, customer support and so on. We've done most of this in-house, so we need developers to make sure it keeps working and to identify new areas we can automate. The majority of this is in PHP. We've got some Java in some back-end places, and then a smattering of Perl, C, and bash scripts filling in the cracks. We've been doing this for over a decade now, so as you can imagine there's a lot of code there. That leads me onto why I wanted to do this talk...

Transcript

  • 1. PHP UK 2009
      • State Machines to State of the Art
      • Smart, Efficient Design using REST and MVC
    Rowan Merewood, Lead Developer, Plusnet
  • 2. Motivation
      • Trying to be a better Software Engineer
  • 3. The Tools
      • HTTP, REST, CRUD, MVC,
      • State Machines
  • 4. HTTP Protocol
      • A stateless way of interacting with resources
  • 5. HTTP Protocol HEAD GET POST PUT DELETE TRACE OPTIONS CONNECT http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9
  • 6. HTTP Protocol HEAD GET POST PUT DELETE TRACE OPTIONS CONNECT
  • 7. HTTP Protocol HEAD GET POST PUT DELETE TRACE OPTIONS CONNECT Safe GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe".
  • 8. HTTP Protocol HEAD GET POST PUT DELETE TRACE OPTIONS CONNECT Idempotent Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request
  • 9. What's Important?
      • User Experience
      • (of course!)
  • 10. What's Important?
      • Safe == Read Only
      • Idempotent == Predictable
  • 11. What went wrong?
      • Great Power -> Great Responsibility?
  • 12. What was abused?
      • HTTP, Sessions, and Cookies – oh my!
  • 13. Safe?
      • http://www.shop.com/buy.php?item=AstonMartin
  • 14. Stateless?
      • I'll just press ”Back” then...
  • 15. REST
      • Representational State Transfer
  • 16. REST
      • Nouns not verbs
  • 17. REST
      • /getOrder?id=123 vs. /order/123
      • /addContact vs. /contacts/
      • /updateArticle?id=abc vs. /article/abc
  • 18. REST
      • REST is ideal for implementing over HTTP
  • 19. Design
      • Enough front-end stuff,
      • what's going to do the work?
  • 20. The Problem
      • Booking train tickets
  • 21. Analysis
      • What's my resource?
      • Tickets
    Origin, Destination, Departs, Class, Price
  • 22. CRUD
      • Create, Read, Update, Delete
  • 23. CRUD Create Delete Update Read Exists PUT/POST DELETE PUT/POST GET
  • 24. Analysis
      • Create, Read, Update, Delete,
      • Book, Cancel, Finalise, Refund, Archive
  • 25. Analysis Create Update Book Finalise Delete Cancel Refund Archive Archive Drafted Refunded Cancelled Deleted Finalised Booked Archived
  • 26. Code Rowan On Rails (I am so, so sorry!)
  • 27. URLs
      • /tickets
      • GET : list tickets
      • POST : create ticket
      • /ticket
      • GET : display ticket form
      • /ticket/123
      • GET : display ticket
      • /ticket/123/booked
      • POST : state transition
  • 28. Controllers
  • 29. Routing
      • $ router = $ frontController ->getRouter();
      • $ route = new Zend_Controller_Router_Route (
      • ' ticket/ :ticketId ',
      • array(
      • ' controller ' => ' ticket ',
      • ' action ' => ' fetch ',
      • )
      • );
      • $ router ->addRoute(' ticketFetch ', $ route );
      • $ route = new Zend_Controller_Router_Route (
      • ' ticket/ :ticketId / :stateHandle ',
      • array(
      • ' controller ' => ' ticket ',
      • ' action ' => ' changestate ',
      • )
      • );
      • $ router ->addRoute(' ticketChangestate ', $ route );
      • $ frontController ->setRouter($ router );
  • 30. Actions
      • public function fetchAction ()
      • {
      • $ model = $ this ->_getModel();
      • $ ticket = $ model ->fetchTicket($ this ->_getParam(' ticketId '));
      • $ this ->view->ticket = $ ticket ;
      • }
      • public function changestateAction ()
      • {
      • $ model = $ this ->_getModel();
      • $ ticket = $ model ->fetchTicket($ this ->_getParam(' ticketId '));
      • if ($ this ->getRequest()->isPost()) {
      • $ model -> setState ($ this ->_getParam(' stateHandle '));
      • $ model -> save ();
      • $ redirector = $ this ->_helper->getHelper(' Redirector ');
      • $ redirector ->gotoRoute(
      • array(' ticketId ' => $ this ->_getParam(' ticketId ')),
      • ' ticketFetch ');
      • }
      • }
  • 31. Model
  • 32. Model
  • 33. Model
      • public function update (Model_TicketData $ data )
      • {
      • $ this ->setState(' Draft ');
      • $ this ->_data = $ data ;
      • }
      • public function setState ($ handle )
      • {
      • $ classname = ' Model_ '.$ handle .' TicketState ';
      • $ state = new $ classname ($ this );
      • $ this ->_state = $ state ;
      • }
  • 34. States
  • 35. States
      • class Model_DraftedTicketState extends Model_TicketState_Abstract
      • {
      • public function __construct (Model_Ticket $ ticket )
      • {
      • $ curState = $ ticket ->getState();
      • if (!$ this ->isValidPrevState($ curState )) {
      • throw new Model_InvalidPrevStateException(
      • ' Tried to move to "Drafted" state from '.$ curState );
      • }
      • }
      • private function isValidPrevState (Model_TicketState_Abstract $ state )
      • {
      • if (
      • is_null($ state ) ||
      • $ state instanceof Model_DraftedTicketState ||
      • $ state instanceof Model_BookedTicketState
      • ) {
      • return true;
      • }
      • return false;
      • }
      • }
  • 36. Benefits
      • Business logic solely in
      • Model_*TicketState classes
  • 37. Benefits
      • Easy to add new states
      • No change to MVC classes
  • 38. Benefits
      • Decoupled
      • I'm tempted to go hook this up to Zend_Rest
  • 39. Cons
      • Lots of classes
  • 40. Cons
      • Method-calling overhead
  • 41. Cons
      • Potential to over-engineer!
  • 42. Questions
      • And possibly answers...