- From: Leigh Dodds <leigh@ldodds.com>
- Date: Tue, 14 Jun 2005 09:32:59 +0100
- To: Paul Downey <paul.downey@whatfettle.com>
- CC: Jan Algermissen <jalgermissen@topicmapping.com>, public-web-http-desc@w3.org, Mark Baker <distobj@acm.org>
Paul Downey wrote: > I'm wondering if by 'generated code' there is an assumption that means > 'canned interaction'. Thats the conclusion that I've drawn from this thread. I could easily see myself generating thin wrappers around an HTTP library to simplify writing code against a given service, even if all it does is assemble a GET or POST request. For nothing more than convenience There's some good points being made about proper handling of response codes (i.e. following the HTTP spec), and service evolution. In the latter case it seems to me that, however sophisticated clients may be, the onus is on the server to avoid breaking changes where possible. As Danny noted, this seems to be a variant of "Cool URIs don't change". I suspect this thread won't get really concrete until we have a draft format and someone generates code from it! At that point the issue will be: is the code generator limited by the data in the format? I've not yet seen a good example of how the code generation use case would introduce "bias" or design artifacts in a description format. That seems like the crux of the discussion here. Whether its a good idea to hard-code parameter names or response codes is more a best practice issue. Something that the format/documentation should discourage, but for quick and dirty hacks, convenient. Cheers, L. -- Home: http://www.ldodds.com Blog: http://www.ldodds.com/blog
Received on Tuesday, 14 June 2005 08:33:21 UTC