Loading ...
Sorry, an error occurred while loading the content.

19209testing clients

Expand Messages
  • Erik Wilde
    Dec 2, 2012
    • 0 Attachment
      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!



      erik wilde | mailto:dret@... - tel:+1-510-2061079 |
      | UC Berkeley - School of Information (ISchool) |
      | http://dret.net/netdret http://twitter.com/dret |
    • Show all 28 messages in this topic