Loading ...
Sorry, an error occurred while loading the content.

CommandQuerySeparation and REST?

Expand Messages
  • Rickard Öberg
    Hi! I m writing a new application for GTD workflows, and wanted to see if I can apply the REST principles to the web API. I have had much good input from the
    Message 1 of 39 , May 4, 2009
    • 0 Attachment
      Hi!

      I'm writing a new application for GTD workflows, and wanted to see if I
      can apply the REST principles to the web API. I have had much good input
      from the discussions here so far, but one thing I need help with.

      Basically, I want the application to use Command and Query separation at
      its root. This means that clients call queries to get state/views out,
      then perform commands on that which are sent back to the server. In
      other words, clients never ever send state back, only commands. So far I
      have resources in my URI structure for the queries, which can be GET,
      and that works quite ok, but then I also have the commands in my URI
      structure, such as:
      /user/123/inbox/createtask
      which when GET returns an empty JSON structure or HTML form, which can
      then be filled in and POST'ed back. There is a domain model on the
      server which interprets and executes this and all the domain logic
      around it.

      But from my reading of the "RESTful web services" this corresponds to
      the REST/RPC hybrid architecture. It is difficult, at best, to do
      caching of resources, since there is no POST/PUT/DELETE which explicitly
      could be used to invalidate resource caches, such as that of
      /user/123/inbox. Using lastmodified/etags for caching works though.

      Does anyone have experience building CQS-systems that have a more
      RESTful approach? How are others dealing with this?

      Thanks,
      Rickard
    • Greg Young
      Then I believe you are saying CQS and REST cannot exist together. A huge part of CQS is carrying forward the context of the original operation while you try
      Message 39 of 39 , May 19, 2009
      • 0 Attachment
        Then I believe you are saying CQS and REST cannot exist together.

        A huge part of CQS is carrying forward the context of the original
        operation while you try really hard to ignore the context. Even if you
        do something like documents (hoping to the source events at the
        server) this will only work in extremely naive circumstances.

        > More importantly, by defining multiple messages carrying intent, you enforce
        > the client to understand those, which is coupling the client to the details
        > of what commands exist, which means the client needs an understanding of
        > each of those commands. I compare that to the case of understanding the
        > media type to send a representation, and understanding how to follow links,
        > and I'd argue that the latter has lower coupling, with higher implementation
        > cost.

        the client knows what operations are actually supported (it being the
        messages contain data as well wouldn't it still need to know about
        them?)? it is the one that represents the behaviors the two are
        conceptually coupled. the only time they are not is when you do not
        have a behavior oriented UI (i.e. they are data oriented). using cqs
        your interface should be behavior oriented (not data oriented).

        Cheers,

        Greg

        On Tue, May 19, 2009 at 4:05 PM, Sebastien Lambla <seb@...> wrote:
        >
        >
        > I don't disagree with you, it's a matter of tradeoffs.
        >
        > Designing a ReST architecture requires the client being instructed in what
        > to do next in the media type definition, aka your document format. This
        > requires a lot of engineering and thoughts in how to design those, including
        > how the interaction can be driven by the server and how the links are to be
        > followed, which makes creating them expensive, but hopefully much more
        > loosely coupled, reusable and durable.
        >
        > If you package the intent and the semantics of an operation within a message
        > and POST to a queue, you may breach many constraints of ReST in the process,
        > which is a tradeoff each developer has to evaluate for themselves.
        >
        > More importantly, by defining multiple messages carrying intent, you enforce
        > the client to understand those, which is coupling the client to the details
        > of what commands exist, which means the client needs an understanding of
        > each of those commands. I compare that to the case of understanding the
        > media type to send a representation, and understanding how to follow links,
        > and I'd argue that the latter has lower coupling, with higher implementation
        > cost.
        >
        > Seb
        >
        > -----Original Message-----
        > From: Greg Young [mailto:gregoryyoung1@...]
        > Sent: 19 May 2009 20:31
        > To: Sebastien Lambla
        > Subject: Re: [rest-discuss] CommandQuerySeparation and REST?
        >
        > Yes things like this can be done ...
        >
        > but when you start going down this path (everything becomes actions
        > like these) don't you really lose much of what you had to benefit
        > fgrom in the beginning? This is why I was saying I prefer to just use
        > a pipeline on the write side.
        >
        > Cheers,
        >
        > Greg
        >
        > On Tue, May 19, 2009 at 3:01 PM, Sebastien Lambla <seb@...> wrote:
        >>
        >>
        >>> Suppose someone does a PUT on /Customer/XYZ/Address and the server
        >>> receives an updated address. Assuming the domain model accepts two
        >>> potential messages for updating an address:
        >>> - CorrectCustomerAddress
        >>> - CustomerHasMovedToNewAddress
        >>>
        >>> Which one command message do you send based on the updated address
        >>> received in the PUT?
        >>
        >> I'd model it by specifying two different resources. Given a GET:
        >>
        >> <address for="/Customer/XYZ">
        >> <action rel="http://actions.acme.org/address-correction" method="put"
        >> href="/Customer/XYZ/Address" />
        >> <action rel="http://actions.acme.org/address-moved" method="post"
        >> href="/Customer/XYZ" />
        >> <content>
        >> <line1>Somewhere</line1>
        >> </content>
        >> </address>
        >>
        >> The UA would process the document, discover two links it can follow with
        > any
        >> modifications to the document it wants to submit, and present the user
        > with
        >> the option of following either links. How the UA presents the two options
        > is
        >> up to how much understanding is hard-coded in the client (for a rel
        > value).
        >>
        >> What we then have is the same representation being sent to two resources,
        >> with various semantics.
        >>
        >> Another option is to make that kind of decisions based on the actual
        > content
        >> of the mediatype. The typical scenario would be in html forms.
        >>
        >> POST /Customer/XYZ/Address
        >>
        >> line1=Somewhere;reason=[correction|moving]
        >>
        >> Another option in html is to simply serve two different pages:
        >>
        >> GET /Customer/XYZ/Address
        >>
        >> <a href="Customer/XYZ/Address/Moving.html">I'm moving</a> or <a
        >> href="Customer/XYZ/Address/Correction">There was a mistake</a>
        >>
        >> Each pointing the result of the form to the correct URI.
        >>
        >> You can have the same *representation* you wish to change used by multiple
        >> *resources*. I don't see why you can't create as many resources as you
        > need,
        >> as intent is carried by the link being followed.
        >>
        >> Seb
        >>
        >>
        >
        > --
        > It is the mark of an educated mind to be able to entertain a thought
        > without accepting it.
        >
        >



        --
        It is the mark of an educated mind to be able to entertain a thought
        without accepting it.
      Your message has been successfully submitted and would be delivered to recipients shortly.