Comments for Peter Williams http://barelyenough.org … and there is much to be learned Sun, 06 May 2012 15:09:26 +0000 hourly 1 http://wordpress.org/?v=3.3.2 Comment on Fun With Public Keys by Johne http://barelyenough.org/blog/2008/04/fun-with-public-keys/comment-page-1/#comment-85875 Johne Sun, 06 May 2012 15:09:26 +0000 http://pezra.barelyenough.org/blog/?p=322#comment-85875 Thanks for this... Thanks for this…

]]> Comment on Developing software as if quality matters by NolaJeffro http://barelyenough.org/blog/2011/11/as-if-quality-matters/comment-page-1/#comment-85824 NolaJeffro Fri, 04 May 2012 16:40:18 +0000 http://barelyenough.org/?p=609#comment-85824 Great flow chart medium... I bet it captures brain storming better than Visio. Great flow chart medium… I bet it captures brain storming better than Visio.

]]> Comment on Hypermedia as the Engine of Application State by Notes on RESTful APIs – wooptoo http://barelyenough.org/blog/2007/05/hypermedia-as-the-engine-of-application-state/comment-page-1/#comment-85822 Notes on RESTful APIs – wooptoo Tue, 17 Apr 2012 06:29:11 +0000 http://pezra.barelyenough.org/blog/2007/05/hypermedia-as-the-engine-of-application-state/#comment-85822 [...] Hypermedia as the Engine of Application State [...] [...] Hypermedia as the Engine of Application State [...]

]]> Comment on REST/HTTP Service Versioning (Response to Jean-Jacques Dubray) by Andy Dennie http://barelyenough.org/blog/2008/05/resthttp-service-versioning-reponse-to-jean-jacques-dubray/comment-page-1/#comment-85812 Andy Dennie Tue, 27 Mar 2012 13:14:09 +0000 http://pezra.barelyenough.org/blog/?p=341#comment-85812 While pondering the approach discussed above, one more use case came to mind which it nicely handles - experimental (beta) releases of new representation versions. For example, suppose that version 1.12 is the latest supported version for general use, but version 1.13 is available for beta testers. A client specifying "application/vnd.myapp-v1+xml;level=5" gets version 1.5, or nothing (a 406). A client specifying "application/vnd.myapp-v1+xml" (i.e. no "level" parameter) gets version 1.12, because the absence of the "level" parameter means "I accept any 1.x", and thus the server is free to return any 1.x version it chooses, in this case the most recent generally available version. However, a beta client could specify "application/vnd.myapp-v1+xml;level=13" and get that version specifically. Nice! While pondering the approach discussed above, one more use case came to mind which it nicely handles – experimental (beta) releases of new representation versions. For example, suppose that version 1.12 is the latest supported version for general use, but version 1.13 is available for beta testers. A client specifying “application/vnd.myapp-v1+xml;level=5″ gets version 1.5, or nothing (a 406). A client specifying “application/vnd.myapp-v1+xml” (i.e. no “level” parameter) gets version 1.12, because the absence of the “level” parameter means “I accept any 1.x”, and thus the server is free to return any 1.x version it chooses, in this case the most recent generally available version. However, a beta client could specify “application/vnd.myapp-v1+xml;level=13″ and get that version specifically. Nice!

]]> Comment on REST/HTTP Service Versioning (Response to Jean-Jacques Dubray) by Andy Dennie http://barelyenough.org/blog/2008/05/resthttp-service-versioning-reponse-to-jean-jacques-dubray/comment-page-1/#comment-85811 Andy Dennie Mon, 26 Mar 2012 14:53:35 +0000 http://pezra.barelyenough.org/blog/?p=341#comment-85811 Peter, first off, thanks very much for your blog posts on this subject; they're really helping me think through things. One question that's not clear to me from your examples... would you use different media types for different resources, or the same one? An example will make this clearer. Say my service exposes Customer resources and Order resources. I can see two possibilities. 1) the media type "application/vnd.myapp-v1+xml;level=12" can be used for both Customer AND Order resources, and in each case simply means the 12th level of the 1st version of the XML representation for that resource. 2) there would be distinct media types "application/vnd.myapp.customer-v1+xml;level=12" and "application/vnd.myapp.order-v1+xml;level=12", each to be used with the corresponding resource. It seems to me that approach #1 could work, since the resource is identified by the URI and therefore doesn't have to be part of the media type. On the other hand, it feels funny for a media type to be so loosely defined that it could be applied to two representations that looking nothing alike. Peter, first off, thanks very much for your blog posts on this subject; they’re really helping me think through things. One question that’s not clear to me from your examples… would you use different media types for different resources, or the same one? An example will make this clearer. Say my service exposes Customer resources and Order resources. I can see two possibilities.
1) the media type “application/vnd.myapp-v1+xml;level=12″ can be used for both Customer AND Order resources, and in each case simply means the 12th level of the 1st version of the XML representation for that resource.
2) there would be distinct media types “application/vnd.myapp.customer-v1+xml;level=12″ and “application/vnd.myapp.order-v1+xml;level=12″, each to be used with the corresponding resource.

It seems to me that approach #1 could work, since the resource is identified by the URI and therefore doesn’t have to be part of the media type. On the other hand, it feels funny for a media type to be so loosely defined that it could be applied to two representations that looking nothing alike.

]]> Comment on Versioning REST Web Services by How are REST APIs versioned? | Lexical Scope http://barelyenough.org/blog/2008/05/versioning-rest-web-services/comment-page-2/#comment-85808 How are REST APIs versioned? | Lexical Scope Mon, 12 Mar 2012 17:19:04 +0000 http://pezra.barelyenough.org/blog/?p=335#comment-85808 [...] Peter Williams [...] [...] Peter Williams [...]

]]> Comment on Versioning REST Web Services by Kari's World » Blog Archive » REST in pieces http://barelyenough.org/blog/2008/05/versioning-rest-web-services/comment-page-2/#comment-85807 Kari's World » Blog Archive » REST in pieces Fri, 09 Mar 2012 20:27:21 +0000 http://pezra.barelyenough.org/blog/?p=335#comment-85807 [...] For API versioning, well, there is some kind of concept ideas: Versioning REST Web Services [...] [...] For API versioning, well, there is some kind of concept ideas: Versioning REST Web Services [...]

]]> Comment on Versioning REST Web Services by Confluence: Engineering http://barelyenough.org/blog/2008/05/versioning-rest-web-services/comment-page-2/#comment-85805 Confluence: Engineering Mon, 05 Mar 2012 16:58:26 +0000 http://pezra.barelyenough.org/blog/?p=335#comment-85805 <strong>SeeMyRadiology API...</strong> Introduction SeeMyRadiology uses the REST architectural style to expose integration functionality. This document describes the media types and representations used by the API. Intended Audience This document is not an introduction to REST....... SeeMyRadiology API…

Introduction SeeMyRadiology uses the REST architectural style to expose integration functionality. This document describes the media types and representations used by the API. Intended Audience This document is not an introduction to REST…….

]]> Comment on REST/HTTP Service Versioning (Response to Jean-Jacques Dubray) by Piers Lawson http://barelyenough.org/blog/2008/05/resthttp-service-versioning-reponse-to-jean-jacques-dubray/comment-page-1/#comment-85803 Piers Lawson Thu, 01 Mar 2012 23:29:15 +0000 http://pezra.barelyenough.org/blog/?p=341#comment-85803 Ah... apologies, your q factor is present... just scrolled off the screen! Ah… apologies, your q factor is present… just scrolled off the screen!

]]> Comment on REST/HTTP Service Versioning (Response to Jean-Jacques Dubray) by Piers Lawson http://barelyenough.org/blog/2008/05/resthttp-service-versioning-reponse-to-jean-jacques-dubray/comment-page-1/#comment-85802 Piers Lawson Thu, 01 Mar 2012 23:26:16 +0000 http://pezra.barelyenough.org/blog/?p=341#comment-85802 A minor point, your example of an Accept header taking alternate content types and then stating version 2 is its preference is slightly wrong. Without a q factor in there, they all default to q=1... which means the server is free to serve whichever version it likes. The HTP spec does not say what should happen in this case. In my framework I default to the order of the Accept types, but as Microsoft's web api team blindly state, they don't have to do this so serving their default is perfectly legal: http://aspnet.uservoice.com/forums/147201-web-api/suggestions/2620003-use-order-of-entries-in-the-accept-header-for-entr?tracking_code=519af301292bc3a981a99d51a6231ba5 I believe they are being short sighted, but the best way to guarentee you get the best possible representation is to use the q factor. Hopefully others will raise this with Microsoft as well... I tried here also: http://forums.asp.net/t/1771514.aspx/1?Accept+type+ordering A minor point, your example of an Accept header taking alternate content types and then stating version 2 is its preference is slightly wrong. Without a q factor in there, they all default to q=1… which means the server is free to serve whichever version it likes. The HTP spec does not say what should happen in this case. In my framework I default to the order of the Accept types, but as Microsoft’s web api team blindly state, they don’t have to do this so serving their default is perfectly legal:

http://aspnet.uservoice.com/forums/147201-web-api/suggestions/2620003-use-order-of-entries-in-the-accept-header-for-entr?tracking_code=519af301292bc3a981a99d51a6231ba5

I believe they are being short sighted, but the best way to guarentee you get the best possible representation is to use the q factor.

Hopefully others will raise this with Microsoft as well… I tried here also:

http://forums.asp.net/t/1771514.aspx/1?Accept+type+ordering

]]>