Showing posts with label Brainstorm. Show all posts
Showing posts with label Brainstorm. Show all posts
October 13, 2010
August 25, 2010
GET /stock-quote/foo vs. getStockQuote("foo")
Consider the good old stock quote example from REST vs. RPC discussions. In both variants two kinds of coupling exist.
On the one hand there is the intentional coupling that causes the client to make the call to that particular remote thing and not just any arbitrary one. The intentional coupling is a human choice, manifested in configuration or code.
On the other hand there is technical coupling because the client software needs to know (aka be coupled to) the provided interface. Otherwise the communication would no be able to happen.
Given those two kinds or layers of coupling it makes no sense whatsoever to repeat the specifics already present in the intentional coupling at the technical level by giving that specific remote thing a specific interface.
Once the intentional choice has been made to talk to that remote thing the interface specifics can be factored away.
Why design, implement, test, maintain, document and explain more stuff if you can do the same things with less?
On the one hand there is the intentional coupling that causes the client to make the call to that particular remote thing and not just any arbitrary one. The intentional coupling is a human choice, manifested in configuration or code.
On the other hand there is technical coupling because the client software needs to know (aka be coupled to) the provided interface. Otherwise the communication would no be able to happen.
Given those two kinds or layers of coupling it makes no sense whatsoever to repeat the specifics already present in the intentional coupling at the technical level by giving that specific remote thing a specific interface.
Once the intentional choice has been made to talk to that remote thing the interface specifics can be factored away.
Why design, implement, test, maintain, document and explain more stuff if you can do the same things with less?
February 13, 2010
Three Aspects of Steady-States
The #rest IRC channel (transcripts here and here) has recently become for me a valuable source for thought stimulation (come and visit). Yesterday we had a discussion regarding steady-states and the following observation has been made:
URIs refer to a certain application state; at least in the sense that one can use a URI to go back to a certain application state or that one can pass a URI to another party to bring this party into that application state.
However, 'that application state' (despite the notion that I can use the URI to get back to it) is not stable over time. The semantics of the mapping are, but the transitions available form that state can change. So, what is the significance of 'that application state'?
I have not figured that out yet, but here is a thought I had this morning as a reaction to the discussion:
A Web application comprises a state machine that can change over time. Each state (aka steady-state) of that state machine has three aspects:
The first of the three is constrained to remain stable over time the other two vary depending on the state of the associated domain concept and the actual state machine the server intends to provide to (that particular) client.
UPDATE: It has come up in a number of places a notion of transient states or ephemeral URIs. As far as I understand the issue circles around the idea of giving distinct URIs to different states of application states. With this approach, an order in some 'review-pending' state would be represented by a different resource (and hence different URI) than the same order in the state 'shipment-initiated'. Please correct me, if I miss the point here.
My response to that can be found in this comment on Ian's blog.
I'd highly apprechiate if someone could shed more light on this issue. I think it is a deep one.
URIs refer to a certain application state; at least in the sense that one can use a URI to go back to a certain application state or that one can pass a URI to another party to bring this party into that application state.
However, 'that application state' (despite the notion that I can use the URI to get back to it) is not stable over time. The semantics of the mapping are, but the transitions available form that state can change. So, what is the significance of 'that application state'?
I have not figured that out yet, but here is a thought I had this morning as a reaction to the discussion:
A Web application comprises a state machine that can change over time. Each state (aka steady-state) of that state machine has three aspects:
- Its semantics (what the state means)
- The serialized state of the associated domain concept (e.g. order 10029)
- The outgoing transitions to other states
The first of the three is constrained to remain stable over time the other two vary depending on the state of the associated domain concept and the actual state machine the server intends to provide to (that particular) client.
UPDATE: It has come up in a number of places a notion of transient states or ephemeral URIs. As far as I understand the issue circles around the idea of giving distinct URIs to different states of application states. With this approach, an order in some 'review-pending' state would be represented by a different resource (and hence different URI) than the same order in the state 'shipment-initiated'. Please correct me, if I miss the point here.
My response to that can be found in this comment on Ian's blog.
I'd highly apprechiate if someone could shed more light on this issue. I think it is a deep one.
Subscribe to:
Posts (Atom)