Our Service Oriented Architecture team is writing very next-level things, such as JSON services that pass data like this:

<JSON>
<Data>
...
</Data>
</JSON>

Your Service Oriented Architecture team needs some assistance in life...

I cannot imagine what would happen if they try to google an issue with generating JSON and wondering why everyone uses {}

@bigus-dickus This is unholy. Do you have a saint water?

what the fuck

*heats up the frying pan*

Spanking time, extra hot.

I would almost feel like strangling the person who came up with this idea just because I dont know of any other appropriate reaction

@IntrusionCM jokes on you I'm into that shit

Some people love XML-RPC. Those people are terrible human beings.

@SortOfTested especially when they confuse it with JSON

@ddit that goes without saying! There is special torturing realm for them. What am I saying? They've already suffered a lot just by going this route, another hell will seem as heaven 😂

First, just because they name a tag json does not turn xml into json.

Sounds more like someone miss-understanding and thinking json to be the root node.

Either way its not json since json is a specified format :)

@SortOfTested > "Some people love XML-RPC"

When JSON was the new XML, a senior dev wrapped WCF responses in JSON (base64 encoded). His justification was JSON is just a string and faster than XML and upper-mgmt bought it.

Terrible person? Yea, he kinda was. 'Tom' quit (before he was fired) over 6 years ago and we still talk about him today.

I was feeling down and needed a confidence boost. This post helped

@PaperTrail
That's just dumb. WCF has json serialization support for SOAP messages if for some reason that is your jam.

Anyways, I'm not really a proponent of rest as the alternative. gRPC with protobuf or avro is not only faster at both ends, it supports serialization-time compression, has better support for schema validation, and is more flexible in that it supports multiple schemas. Anyone still mainlining WCF, or any XML-RPC framework should really consider investigating it, now that WCF is scheduled for sunset. And since not paying for windows server is its own reward, it also runs on Linux.

You should suggest they remove the JSON tags for a peformance boost. They might like that lol

@SortOfTested > "That's just dumb"

Oh boy, wait until you see the code.

I think one of the straws (yes, more than one straw that broke the camel's back) when very large WCF responses were being returned, he use GZip to compress/de-compress the json string, bragging how much bandwidth he was saving (and lower bandwidth = faster performance, faster = profits, etc). Yep, upper-mgmt bought that story too.

What the fuck is this.
Seems like XML and JSON had an unwanted child and attempted to abort it, but sadly it didn't work out and shortly after birth, they discarded it in a dumpster fire.

Why did u futck the hornet nest?

It was a joyful adrenalin rush ... For a few milisecs.

I gave up on reasoning with devs.

Above example is the common metaphor in my brain regarding most devs conversations who think they've solved a problem "much smart much clever so wow"

@SortOfTested protobuf is good but for an external api it is not whatI would choose.

Json has the benefit of being reasonably compact while being both human readable and writable which makes experimentation while implementing a client easier.

@Voxera
That just seems like a tools familiarity issue. My APIs support json, xml, protobuf serialization, avro for my data services.

Boiling it down, none of the data is human readable without an application. Your application just happens to understand json. There's numerous extensions for browsers, terminal commands, httpie, vscode, jetbrains, eclipse, etc for viewing protobuf, avro, etc.

I'm not willing to give up a 10x perf bonus to cater to a notepad workflow. The good news is, you don't have to; you can use multiple serialization targets.

@SortOfTested sure you can, but when the clients are customers and ease of use is much more important than performance json wins over protobuf.

But for internal use, sure, especially when we was storing in redis or between our own systems.

Most customers would never have heard or been able to use protobuf, some of them used string concatenation to build payloads ;)

So offering multiple formats would only have been a complication.

Sometimes you have to be pragmatic.

@Voxera
We'll just have to agree to disagree. My business is selling data services, and we saw an enormous adoption when we released our binary serialization options, primarily because they're streamable. JsonL is our most popular format, I imagine that would change if we did any evangelising beyond sending out an email notifying them of the availability.

I can say for sure, your customers will definitely never adopt what you don't release.

@SortOfTested well it was my former job, but having contact with several of the customers I really dough it would be of interest. I think by the end we probably had around a thousand api customers and they only ever wanted json.

So either way its not my business longer :)

And the current does not involve external apis so not relevant.

So we're here at last, the beginning of the end!!!