testing clients
Erik Wilde <[email protected]>
| Newsgroups | gmane.comp.web.services.rest |
|---|---|
| Message-ID | <[email protected]> |
hello matt. On 2012-12-02 08:44 , Matt McClure wrote: > Even then, if you can't prevent client developers from "deep linking" > into your API, how do you handle breaking changes for those clients? this is a very good question. one important aspect is that it's always bad if clients are tested against just one implementation. server programmers often put quite a bit of effort into designing pretty URIs, which is good. but this also lures client programmers into relying on those patterns, and as long as you just test against one implementation, things often work fine. however, often there only is one implementation to test against, so what then? something i've been thinking about (and nothing more, and also i haven't seen any frameworks supporting this) would be that server frameworks could have a "test" switch, that would start serving "ugly" and pretty much random URIs, instead of the pretty designed ones. a test installation could then be easily provided to client programmers, and their code would break very quickly in all places where they took shortcuts, instead of following links. i haven't seen support for this so far, but it seems to me that in many REST-oriented server-side frameworks, this might not be all that hard to add. if somebody has seen such a thing in practice, please let me know! cheers, dret. -- erik wilde | mailto:[email protected] - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret |