- Overall purpose of the service (aka the realized business process role)
- What client goals does the service enable (aka protocol operations)
- When can the client expect certain goals to be available (aka partial ordering of application states)
- What does the client have to do to 'execute' a certain goal (aka hypermedia semantics)
December 7, 2009
November 27, 2009
First, there is the question, whether the initial creation of a replicated item in the slave should be performed by a request from the master to the slave or by a request from the slave to the master. The former will often be chosen when there is a business rule involved that should trigger the replication (e.g. replicate all employees in the slave system whose contract ends in 6 months). The latter is more likely to be used in a scenario where the slave replicates all new items in the master, in other words, where the slave keeps the overall set of items in sync.
Second there is the question how updates of the items in the master are made available in the slave. This is the classic distinction between polling and publish/subscribe: Should the master notify the client of updates or should the slave poll for updates?
In addition, there is sometimes a desire to notify the master about changes the slave makes to the replicated items. The intention of this scenario is not the bidirectional synchronization of master and slave but reflects the master's interest in any changes the slave makes.
What is the guiding principle to make an informed design decision regarding the direction of communication in such a replication scenario? The answer is separation of concerns with the goal of simplicity and avoiding unnecessary coupling. This leads to the question which of the systems should for which communication play the server role and which one should play the client role?
Every communication is initiated to achieve some goal and the correct separation of concerns puts the component that acts to achieve the goal into the client role and the other component into the server role.
Applied to the above scenarios this means that for initial replication and subsequent updates the slave system should act as a client and the master should act as a server. All the necessary resources to be provided by the sever (e.g. providing list of all items that match a business rule) can be derived.
Applied to the scenario where the master is interested in updates from the slave it means that the master should act as the client because it is the master that has the goal (the slave does not care at all). This leads to certain resources that need to be exposed by the slave.
I have seen at least three production systems that had this issue and all of them did it wrong and would have greatly benefited in terms of simplicity and loose coupling from following the above principled design path.
Related is Roy's post Paper tigers and hidden dragons.
November 26, 2009
November 25, 2009
That is why we have a WebDAV working group. Both the 300 and 406 response bodies were left unspecified because the intention was that they be specified by a group that actually had time to study the problem in detail and come up with a [hopefully] better solution than some off-the-cuff invention of mine. It was one of the WebDAV to-do items, last time I checked.
Has this ever been done? Maybe it is time to create some standard 300 and 406 response media type?
November 17, 2009
November 5, 2009
November 3, 2009
- While the freedom that is usually (deliberately) given to servers in Internet specifications improves evolvability it is not a sufficient basis for establishing legal contracts between service consumers and service providers. If you make a serious investment into implementing a client to some service then RFC 2119's SHOULD is probably not the best contractual basis.
- If a service makes use of a variety of media types, extensions, link relations, categories, etc. then how would one express this in a formal way?
- If a client is dependent on the presence of some Atom extension in Atom entry documents for example, how could the service provider state that they are committed to providing that extension?
October 27, 2009
In a RESTful system the contract between client and server is expressed solely in the form of hypermedia specifications. On the Web this works fine, because there is usually always a human being involved that can act as the ultimate arbiter of semantics when things need to be decided that happen not to be covered by the involved hypermedia specifications.
1. When I want to buy a book, what hypermedia is telling me that www.amazon.de is a place to go?
2. When the Amazon site is not reachable, how do I find out where else I could buy a book?
3.How do I know what 'buying a book' means and what the basic sequence of operations is that need to be executed in order to achieve the overall goal?
4. How do I figure out, what the new appropriate sequence of operations is should Amazon significantly change its understanding of the flow of a book purchase?
All of the above are ultimately solved by a human being in the case of the Web and usually don't cause any trouble.
3. is particularly interesting because the fact that no hypermedia specification even touches that question reveals that there is a very high level, common sense contract in operation between human clients and some Web applications.
4. is also interesting because economic sense will usually keep e.g. a book seller from changing the flow of operations in a way that causes the potential buyer to not being able to buy anymore.
How does all this relate to IT governance?
When one applies REST (HTTP that is in practice) in an enterprise IT context, these hidden contracts matter because they either need to be covered by hypermedia specifications (e.g. for the discovery/equivalence examples 1. and 2.) or at least need to be made explicit so they become manageable in an IT governance sense.
Example 3. relates to the general question of how types of services (e.g. 'procurement seller role' or 'repository') can be expressed to provide guidance to client developers regarding the intended sequence of operations.
Example 4 relates to the question of how change can be managed not of the pertaining hypermedia specifications (this is easy!) but of their composition (which is what effectively forms the service type).
Besides being able to frame the problem and ask the questions I do not yet have definitive answers - comments and thoughts are very welcome.
lass="Apple-style-span" style="font-size:medium;"> The term 'hypermedia specification' is meant as a general expression for specifications of media types, media type extensions, link relations and 'little' things like category definitions (used for example by Atom and NewsML2).
October 26, 2009
October 10, 2009
October 1, 2009
- unary link, e.g service(x)
- binary relationship, e.g. edit-media(u1,x)
- pattern match on representation of x, e.g. r-match( xpathExpr , x)
- pattern match on occurrance of x in representation, e.g match( xpathExpr , x)
September 30, 2009
September 29, 2009
|201 Created||URI of created resource||Client is notified that a new resource has been created an can dereference the URI to see what has been created, e.g. to verify its expectations.|
ETag can be used to provide current ETag of created resource
|204 No Content||URI of created resource(?)||Clarification pending|
|300 Multiple Choices||URI of server's preferred variant|
|301 Moved Permanently||New permanent URI|
|302 Found||Temporay URI to use for requests to the intended resource|
|303 See Other||Response to the POST request is found at another URI||If client follows redirect and if the client already knows the target resource the 303 works as a notification that the previous POST has changed the target resource.|
|305 Use Proxy||URI of proxy to use for the request.|
|307 Moved Temporarily||Temporary URI to use for requests to this resource.|
201 and 303 provide the grounds for interesting generic client behavior. About the nature of 305 I am not sure yet but the server's ability to redirect a client to an intermediary smells interesting.