We plan to implement #JSON output in our #DNS investigation tool dnsi. There is informational RFC 8427 for representing DNS messages in JSON, but we’d like to see if there is a more ergonomic way of representing such a format. We'd love to hear about your use cases and wishes. https://github.com/NLnetLabs/dnsi/issues/12
Just encountered the #EDIFACT standard while in touch with our logistics firm. Why the hell is this nothing readable and yet another useless standard that could've been implemented in #protobuf#json or something modern....
And the best part is everyone uses a subset or has some customizarions which forces us to implement it again and again
#TechnicalWriting#APIs#APIDocumentation#AsynchronousAPIs#AsyncAPI#EventDrivenAPIs#ApacheAvro#JSON: "Luckily there's a specification similar to OpenAPI but directed at defining event-driven APIs. I'm talking about AsyncAPI. It's a specification that lets you define an API that's asynchronous in nature. By using AsyncAPI you can define, among other things, the different topics where events will be dropped, and the shape of the messages that represent each topic.
And this is where things get interesting. The shape of messages or, in other words, its payload, can adhere to specific standards. Without messages, there's no way to communicate events. And, following standards helps to guarantee the correct publishing, transport, and consumption of messages. If messages don't follow any standards, it's hard for developers to understand the shape of the messages. In addition, it's easy for consumers to stop working because, suddenly, messages are being shared in a slightly different format.
Among different message standards, there's one particularly interesting to me. Apache Avro isn't just a theoretical standard. It's also a serialization format. You can say it's a competitor to JSON but specialized in working with event-driven APIs. In the same way you can use JSON Schema to define the shape of JSON data you have Avro Schema to help you specify what Avro message payloads look like."
We've just published a series of 17 (!) posts on common patterns in JSON Schema; lots of these have been culled from questions asked in the JSON-Schema Slack channel.
They are written from the perspective of .NET developers who are used to JSON serialization as a code-first exercise, and want to migrate towards schema-first (with generated code examples from Corvus.JsonSchema).
@dbushell@pablolarah We've got Drupal making crazy nested structure of entities on one side, and Wordpress dumping everything in flat text fields with magic markup tags... Opposite approaches but both badly flawed.
JSON is usually beautifully simply and useful. I'm starting to see the same un-necessarily over-complicated nesting of simple data by API vendors as the XML crowd. All I'm missing is Base64encoded JSON inside of Base64encoded JSON.
@derickr The value out of the DB call is effectively a string. I can (and did) change that, the frustration is they want it as a number in one place, and the same value as string in another. and they did this in multiple fields.
In my head there is only text. It's all just text. But that's just my strange way of looking at things.
TIL about the #WordPress Block Data API - used for retrieving block editor posts structured as #JSON data, with integrations for both the official WordPress REST API and #WPGraphQL.
Primarily designed for use in decoupled WordPress.