At Gragg, I've been experimenting with a different approach: I wrote a self-describing schema language for all of the JSON payloads that'd be sent, wrote a service and tested it with a "blob" type that doesn't validate, then wrote the spec when it was clear enough, then it turns out that writing a client from the spec is usually super-simple, you get to see all of the things which the spec can do.

Here's the basic things that have been mostly useful:

    Maybe x, for optional parameters.
        Process by defining what to do when null.
        Doesn't have to be tagged to be useful.
    Repetition in the form of [x] and Map String x.
        Process only via a for-each loop.
    Tagged-sums-of-products: ["tag", arg1, arg2, ...]
        Process only with a switch statement dispatching over arr[0].
    Record types like {"id": 3, "name": "Gandalf", "color": "grey"}
        Feel free to base logic on record.name etc.
    Primitives: dates, ints, strings, blobs.

The tagged-sums bit is probably a dealbreaker for me at this time: I picked this up from Haskell and I would not easily let go. The syntax in JSON is a little clumsy, but it's still important. Cf. Abelson and Sussman's lectures, "All interesting programs start with a case dispatch."