JSON responses -- what's your preference?

[realJSOP]

Not to mention the newest crop of "programmers" that we're starting to see...

".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013

[dan sh]

Second, of course. Unless I try to go bonkers, then it is this:

[{
"PropertySet": [{
"Id": "1",
"Name": "fancyProperty",
"Type": "String",
"IsArray": "true"
}],
"ValueSet": [{
"PropertySetId": "1",
"Value": "AM"
},
{
"PropertySetId": "1",
"Value": "DI"
},
{
"PropertySetId": "1",
"Value": "EB"
},
{
"PropertySetId": "1",
"Value": "EP"
},
{
"PropertySetId": "1",
"Value": "MC"
},
{
"PropertySetId": "1",
"Value": "VI"
}
]
}]

"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[^]

[Scott Serl]

Just because a service call works, doesn't mean it is correct. Many internet services incorrectly implement the rfc (dns, smtp, many more...).

[Richard Deeming]

Definitely #2, especially if it's returned from a GET request: Anatomy of a Subtle JSON Vulnerability | You’ve Been Haacked[^]

---

"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

[Chris Maunder]

The second. As you say it's maintainable, plus more easily extensible, and I like having an actual name by which to refer to the data (just seems easier when debugging in DevTools)

cheers Chris Maunder

[dandy72]

I swear I read that subject line as "JSOP responses". I thought I was about to read something with a title such as "The Complete Works of JSOP: All the Sage Wisdom and Life Advice You'll Ever Need as a Collection of One Liners".

[dandy72]

#realJSOP wrote:

newest crop of "programmers" that we're starting to see...

"Starting", he said... Never lose your sense of humor, JSOP.

[Super Lloyd]

do you prefer C# method to return List<T> GetSomeData<T>() or T GetSomeData<T>() if one or the other, why? Personally I don't care either way. Same for JSON.

A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!

[bence98]

I also thought that a valid JSON document has to have a root object. Is it not the case then? Anyways, I prefer the first one because it's shorter, and since it is a response, you should already well know what's gonna be in it: exactly the data requested. However, I have had some issues with the Java JSON library being unable to parse arrays by themselves. As a result, the way it's implemented in production right now (as suggested by StackOverflow :P ) is as follows: - JSON comes in on the network, looking like the first example you gave - Function checks if it starts with '[' and finds that yes, it does - So it appends some string around the received text, making it look like the second one - JSON lib parses this. The returned JsonObject's only JsonArray member is saved, the rest discarded - Prod code gets this JsonArray back to do whatever Fun times! "I don't think about dying. It is the last thing I want to do. :) " - theoldfool

[agolddog]

I prefer the latter. As you point out, it's future-proofed for additions. Also, it can be easily deserialized into a C# object using something like Newtonsoft. That's where I'm generally consuming these data. That might be an important consideration; just because nobody's planning to deserialize into C# (or whatever) today, it means no refactoring when they do.

[Kirk 10389821]

Personally, I prefer to always have the response wrapped. First, it makes it easier to extend in the future without breaking things. I have been around long enough, that code I wrote in the 1980s is still being used today! And the hardest thing to adjust is the data structure changes, because it impacts everything! Next, it just seems more consistent to always be wrapped. I could be biased by using a system or two that were always wrapped. And their inner objects were always consistent objects, and moveable between other container objects.

[Lost User]

Anything that is self-documenting is a good thing, IMO (#2).

"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal

[paheal]

So your preferred answer to GET payment methods is a single object? Academically, I'd say the direct json array is the correct format. Here's an example endpoint and response from GitHub to retrieve followers. However, people have been doing practical choices over academic ones since the dawn of time. If your in control of both the api and the client, knock yourself out, as long as you're consistent.

[maze3]

Here is my 2 cents of crazy. In JS I have an Array. let my_array = ["hi"]; It is going well. push, pop, shift, filter, map... Now I want to add some number counter say Groups, to save searching how many distinct groups are in the Array? my_array._groups = 44; So that works. I can check the number of groups. Now I need to store my my_array. JSON? Well, JSON.stringify(my_array), only captures the array and does not include _groups. Using an object my_array = {array=["hi"]}; we store _groups =44. Now JSON.strinigy contains _groups. but calls to array require either putting through a wrapper object to pass through functions, or adding .array between the functions. Conclusion: I am not sure what my brain is thinking today. Maybe the second wrapper has benefits as you said. :)

[thewazz]

data.d

i forget how relevant this is, but maybe? :) Anatomy of a Subtle JSON Vulnerability | You’ve Been Haacked[^] Edit: haacked • January 2nd, 2017: I don't think any modern browsers have this flaw anymore.