David Storrs wrote on 2/4/19 1:34 PM:
I was specifically thinking of JSON.
Especially if your service interface is always through HTTP/HTTPS, there's a good chance that JSON is a great choice for your application. (If data will be accessed by someone else directly from files or database blobs in this encoding, rather than always coming from the code of your server, that might have more of a life-of-its-own quality, and maybe XML becomes a little more attractive than it was before.)
When you do a server interface in JSON, you have to do more documentation than XML, and be strict about server-side checking:
* If the other side is general solid software engineers / programmers, you just need to do good specs, which includes having to be explicit about some things that are implied with XML. With checking as a backup to oopses, and to rule out some causes when debugging (preferably at least as much as XML would've ruled out).
* If the other side is solid enterprise people who prefer XML, but are willing to do JSON, you also need that good documentation. For good engineering, and perhaps to reassure them that this is not substandard.
* If the other side is a brogrammer "smashing some code" by shotgunning Red Bull to wash down off-label abuse of other substances, while typing syntax flat-out at 200 wpm, they might only skim your docs for a message template they can copy&paste, and wing it from there-- so it's a good thing that you're validating the heck out their messages at whatever syntactic and semantic levels you can. :) This is one of those times that usually-good Internet protocol advice of "...liberal in what you accept" is a bad idea (silent HTML "quirks handling", starting in the early browsers, was another bad time, in hindsight).
Good news for Racket: For doing processing on JSON, like writing and reading and validation and mapping and transformation, Racket DSLs and/or list-processing skills might let you do it much better than you could, were you armed only with JS.
BTW, you *could* also do both XML and JSON. For example: for some Web services, coming from a very complicated data model, IIRC, the engineering process scenario was something like originally the requirement was for XML, and then JSON was added as a requirement, and additional services were added at some point, and engineering resources were tight. What I ended up doing, that time, was defining a conceptual mapping from a subset of XML to JSON encoding, so that a programmer wrote the code to construct the XML message, and got JSON for free. You can see many ways to do something like this, and your implementation might involve a DSL (perhaps in terms of the data model also used by your documentation, and your DSL can even generate Scribble for the XML and JSON interface specs for the documentation, separate from any Racket API documentation).
BTW, if you end up doing reading of large JSON, and want to stream it like SSAX can, rather than slurp it all into memory first, a learning exercise a while ago showed it could be done, with a weird but potentially useful API. (I should've emphasized the "learning exercise" note that's in the docs, as a liability disclaimer, so just treat this as proof-of-concept that you can do JSON processing as streaming, if you ever need to.) https://www.neilvandyke.org/racket/json-parsing/
-- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
