Wednesday, April 28, 2010
Monday, April 26, 2010
architecture group constraining a set of services across an enterprise? For example, suppose a particular architectural style gives us 6 constraints and a specific architecture has 3 additional constraints. Those 3 constraints are, typically, hidden as implementation details but they should be highlighted and reasoned about in the same way that the style itself was.
Wednesday, April 21, 2010
Imagine the URLs to all resources except the static bookmark had a variable number of random numbers somewhere in the path and changed on each request. Would your client still work? Would your service's documentation still be correct?
Is it possible to answer yes to both questions and still break the hypermedia constraint?
Wednesday, April 07, 2010
This feels like a terrible idea. "Fixed URIs"... it just sounds wrong in a hypertext driven ecosystem. Must be a better way. Why couldn't this be addressed by defining good site-* link relations?
RFC 5785: Defining Well-Known URIs: "
This first piece of the discovery stack was published today as an RFC. RFC 5785 defines a registry for new well-known URIs which will provide a standard location for the host-meta document. This work started a year and a half ago as a well-known document called /site-meta, and slowly evolved into a simple registry. While this isn’t a breakthrough idea, it does codify existing behavior and hopefully encourages people to share ideas, discuss proposals, and reusing existing well-known URIs.