3 ms·

In case you're thinking, "Wow, I bet in the real world this would be a misery to impose on a team - I'm sure no one would really want to do this!", well, I work

In case you're thinking, "Wow, I bet in the real world this would be a misery to impose on a team - I'm sure no one would really want to do this!", well, I worked briefly with a team where they imposed this. It was part of the reason why I say "briefly".

jimktrains2 12y ago
I've been starting using it on a personal project and it doesn't seem so bad. What issues did you have? (so I can be forwarned)
- bshimmin 12y ago
  Well, obviously it's very prescriptive. In theory that should mean it requires less mental effort because it tells you what you should be doing - in practice, I found it required more effort to do things the precise way it wanted. I was far from alone in this belief. My main issue was with the "related/linkage" stuff (which may or may not have changed somewhat since I was exposed to it), which is unpleasant, to my eyes, in the way it is expressed, and also verbose and often duplicative in what it produces. A related problem was the Node.js implementation we were using, which generally felt like more of a hindrance than a help (and which we ended up extending beyond all recognition, making matters dramatically worse - though that was no fault of JSON API itself directly, other than by association). Best of luck!
drostie 12y ago
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."

jimktrains2 12y ago

I've been starting using it on a personal project and it doesn't seem so bad. What issues did you have? (so I can be forwarned)

bshimmin 12y ago
Well, obviously it's very prescriptive. In theory that should mean it requires less mental effort because it tells you what you should be doing - in practice, I found it required more effort to do things the precise way it wanted. I was far from alone in this belief. My main issue was with the "related/linkage" stuff (which may or may not have changed somewhat since I was exposed to it), which is unpleasant, to my eyes, in the way it is expressed, and also verbose and often duplicative in what it produces. A related problem was the Node.js implementation we were using, which generally felt like more of a hindrance than a help (and which we ended up extending beyond all recognition, making matters dramatically worse - though that was no fault of JSON API itself directly, other than by association). Best of luck!

drostie 12y ago

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."