BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Presentations The Counterintuitive Web

The Counterintuitive Web

Bookmarks
53:50

Summary

Ian Robinson considers that programming for the web requires a different architectural approach than for applications: clients are interested only in URIs, clients are responsible for the integrity of a sequence of requests, and one should implement application protocols as protocol resources , not domain resources.

Bio

Ian Robinson (http://iansrobinson.com) is a Principal Consultant with ThoughtWorks, where he specializes in the design and delivery of service-oriented and distributed systems. He has written guidance for Microsoft on implementing integration patterns, and has published articles, most recently in The ThoughtWorks Anthology. He is currently co-authoring a book on RESTful enterprise integration.

About the conference

QCon is a conference that is organized by the community, for the community.The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community.QCon is designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.

Recorded at:

Nov 03, 2010

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • What's wrong with having to peer inside the body?

    by Bediako George,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    One of the reasons peering inside the body causes issues is that it leads to code in your controllers/handlers that looks like this ...

    if (body has this)
    {
    //this stuff
    }
    else if (body has that)
    {
    //that stuff
    }
    else if (body has the other)
    {
    //the other stuff
    }
    else if (etc ...


    Instead think of separating each of those state checks in separate controllers each referenced by a single URI. For every "if else" you may need another resource. In this way the URI act as a type of router, automatically routing the resource you are changing to the right controller.

    A direct side effect of this is easier to understand code, greater decoupling, and in my opinion less bugs created by trying to wrap your minds around all those if statements.

    This video is a very good treatment on resource oriented design and Rest.

    Impressive.

  • Did he just make stuff up.

    by William Cherry,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Seems like the first two examples he presented were just complete BS. Who would write code (and call it a REST service) when it completely violates all principles of REST. No one that has been a programmer for more then three days is going to write an Order "service" that is so course grained that it handles completely different payloads at the same URI/method. The ..\Order\123 GET should get a resource named 123, ..\Order PUT, creates a resource, ..\Order\123 POST should modify the order. Period. There might have been useful information in this talk but I couldn't make it past the premise that a professional developer would write services of this armature nature.

  • Re: What's wrong with having to peer inside the body?

    by Nat Pryce,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Not if you use an OO design in your service.

    In that case, the handler looks up an unmarshaller keyed by the content type of the body, uses the unmarshaller to turn the bitstream of the body into a running object, tells the object to act. and the object does whatever it does.

    E.g.

    Unmarshaller unmarshaller = unmarshallers.lookUp(request.contentType);
    PostAction action = unmarshaller.unmarshall(request.body);
    action.performUpon(theActualResource);

  • Re: Did he just make stuff up.

    by John Schlesinger,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I think you got PUT and POST the wrong way around. PUT is idempotent (if I replace the resource twice the end result is the same) whereas POST is unsafe and creates a new resource.

    ... The ..\Order\123 GET should get a resource named 123, ..\Order PUT, creates a resource, ..\Order\123 POST should modify the order. Period. ...

  • Re: What's wrong with having to peer inside the body?

    by Bediako George,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    How did you create the request.contentType? How does the lookUp method choose the right marshaller? If there any if-then-else-if statements in any of those?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT