JSON responses -- what's your preference?
-
Do you prefer to always wrap the JSON in an outer object? For example, a call to a credit card processor to get supported credit cards. Do you prefer simply the array returned:
[
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
]or the array wrapped in an outer "object":
{
"PaymentMethods": [
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
]
}If one or the other, why? Personally, I'm leaning toward the second form, which forces the Javascript writer to at least initially use the
PaymentMethodstag:let ccs = resp.PaymentMethods;Which I think improves code readability. It's also more maintainable IMO, as perhaps other tags at some point might be added -- one simple thing that comes to mind is a flag that indicates whether ACH is supported (mind you, these are all concrete examples of the general question of JSON tags):{
"PaymentMethods": [
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
],
"SupportsACH": true
}Using an outer object wrapper doesn't break the code if additional JSON elements are added later. So...thoughts? Marc
Latest Article - Azure Function - Compute Pi Stress Test Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
2nd one for sure, helps with deserialization as well. You end up with a better formed object model.
Nish Nishant Consultant Software Architect Ganymede Software Solutions LLC www.ganymedesoftwaresolutions.com
-
Do you prefer to always wrap the JSON in an outer object? For example, a call to a credit card processor to get supported credit cards. Do you prefer simply the array returned:
[
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
]or the array wrapped in an outer "object":
{
"PaymentMethods": [
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
]
}If one or the other, why? Personally, I'm leaning toward the second form, which forces the Javascript writer to at least initially use the
PaymentMethodstag:let ccs = resp.PaymentMethods;Which I think improves code readability. It's also more maintainable IMO, as perhaps other tags at some point might be added -- one simple thing that comes to mind is a flag that indicates whether ACH is supported (mind you, these are all concrete examples of the general question of JSON tags):{
"PaymentMethods": [
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
],
"SupportsACH": true
}Using an outer object wrapper doesn't break the code if additional JSON elements are added later. So...thoughts? Marc
Latest Article - Azure Function - Compute Pi Stress Test Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
No-brainer. 2nd as you say. Another reason is: another day, another person may look at your data or code. That other person might be yourself, in a galaxy far far away. I usually like to spend good time on naming things cleanly.
"If we don't change direction, we'll end up where we're going"
-
Do you prefer to always wrap the JSON in an outer object? For example, a call to a credit card processor to get supported credit cards. Do you prefer simply the array returned:
[
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
]or the array wrapped in an outer "object":
{
"PaymentMethods": [
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
]
}If one or the other, why? Personally, I'm leaning toward the second form, which forces the Javascript writer to at least initially use the
PaymentMethodstag:let ccs = resp.PaymentMethods;Which I think improves code readability. It's also more maintainable IMO, as perhaps other tags at some point might be added -- one simple thing that comes to mind is a flag that indicates whether ACH is supported (mind you, these are all concrete examples of the general question of JSON tags):{
"PaymentMethods": [
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
],
"SupportsACH": true
}Using an outer object wrapper doesn't break the code if additional JSON elements are added later. So...thoughts? Marc
Latest Article - Azure Function - Compute Pi Stress Test Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
I go with the second version as well and for the reasons stated. We all know that the only thing constant is change so the second form is a no brainer!
I do all my own stunts, but never intentionally! JaxCoder.com
-
Do you prefer to always wrap the JSON in an outer object? For example, a call to a credit card processor to get supported credit cards. Do you prefer simply the array returned:
[
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
]or the array wrapped in an outer "object":
{
"PaymentMethods": [
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
]
}If one or the other, why? Personally, I'm leaning toward the second form, which forces the Javascript writer to at least initially use the
PaymentMethodstag:let ccs = resp.PaymentMethods;Which I think improves code readability. It's also more maintainable IMO, as perhaps other tags at some point might be added -- one simple thing that comes to mind is a flag that indicates whether ACH is supported (mind you, these are all concrete examples of the general question of JSON tags):{
"PaymentMethods": [
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
],
"SupportsACH": true
}Using an outer object wrapper doesn't break the code if additional JSON elements are added later. So...thoughts? Marc
Latest Article - Azure Function - Compute Pi Stress Test Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
Do you prefer to always wrap the JSON in an outer object? For example, a call to a credit card processor to get supported credit cards. Do you prefer simply the array returned:
[
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
]or the array wrapped in an outer "object":
{
"PaymentMethods": [
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
]
}If one or the other, why? Personally, I'm leaning toward the second form, which forces the Javascript writer to at least initially use the
PaymentMethodstag:let ccs = resp.PaymentMethods;Which I think improves code readability. It's also more maintainable IMO, as perhaps other tags at some point might be added -- one simple thing that comes to mind is a flag that indicates whether ACH is supported (mind you, these are all concrete examples of the general question of JSON tags):{
"PaymentMethods": [
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
],
"SupportsACH": true
}Using an outer object wrapper doesn't break the code if additional JSON elements are added later. So...thoughts? Marc
Latest Article - Azure Function - Compute Pi Stress Test Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
Do you prefer to always wrap the JSON in an outer object? For example, a call to a credit card processor to get supported credit cards. Do you prefer simply the array returned:
[
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
]or the array wrapped in an outer "object":
{
"PaymentMethods": [
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
]
}If one or the other, why? Personally, I'm leaning toward the second form, which forces the Javascript writer to at least initially use the
PaymentMethodstag:let ccs = resp.PaymentMethods;Which I think improves code readability. It's also more maintainable IMO, as perhaps other tags at some point might be added -- one simple thing that comes to mind is a flag that indicates whether ACH is supported (mind you, these are all concrete examples of the general question of JSON tags):{
"PaymentMethods": [
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
],
"SupportsACH": true
}Using an outer object wrapper doesn't break the code if additional JSON elements are added later. So...thoughts? Marc
Latest Article - Azure Function - Compute Pi Stress Test Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
I prefer the road that is more and more "less travelled" - the right way, which is the 2nd option.
".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 -
Do you prefer to always wrap the JSON in an outer object? For example, a call to a credit card processor to get supported credit cards. Do you prefer simply the array returned:
[
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
]or the array wrapped in an outer "object":
{
"PaymentMethods": [
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
]
}If one or the other, why? Personally, I'm leaning toward the second form, which forces the Javascript writer to at least initially use the
PaymentMethodstag:let ccs = resp.PaymentMethods;Which I think improves code readability. It's also more maintainable IMO, as perhaps other tags at some point might be added -- one simple thing that comes to mind is a flag that indicates whether ACH is supported (mind you, these are all concrete examples of the general question of JSON tags):{
"PaymentMethods": [
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
],
"SupportsACH": true
}Using an outer object wrapper doesn't break the code if additional JSON elements are added later. So...thoughts? Marc
Latest Article - Azure Function - Compute Pi Stress Test Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
GuyThiebaut wrote:
turns out I am wrong about the not valid statement I made
:-D Given I copied the response from the actual service call....
Latest Article - Azure Function - Compute Pi Stress Test Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
I prefer the road that is more and more "less travelled" - the right way, which is the 2nd option.
".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#realJSOP wrote:
I prefer the road that is more and more "less travelled"
It's becoming harder and harder to find that road. The weeds of innovation, latest techniques, and best practices[^] are taking over.
Latest Article - Azure Function - Compute Pi Stress Test Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
#realJSOP wrote:
I prefer the road that is more and more "less travelled"
It's becoming harder and harder to find that road. The weeds of innovation, latest techniques, and best practices[^] are taking over.
Latest Article - Azure Function - Compute Pi Stress Test Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
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 -
Do you prefer to always wrap the JSON in an outer object? For example, a call to a credit card processor to get supported credit cards. Do you prefer simply the array returned:
[
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
]or the array wrapped in an outer "object":
{
"PaymentMethods": [
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
]
}If one or the other, why? Personally, I'm leaning toward the second form, which forces the Javascript writer to at least initially use the
PaymentMethodstag:let ccs = resp.PaymentMethods;Which I think improves code readability. It's also more maintainable IMO, as perhaps other tags at some point might be added -- one simple thing that comes to mind is a flag that indicates whether ACH is supported (mind you, these are all concrete examples of the general question of JSON tags):{
"PaymentMethods": [
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
],
"SupportsACH": true
}Using an outer object wrapper doesn't break the code if additional JSON elements are added later. So...thoughts? Marc
Latest Article - Azure Function - Compute Pi Stress Test Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
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[^]
-
GuyThiebaut wrote:
turns out I am wrong about the not valid statement I made
:-D Given I copied the response from the actual service call....
Latest Article - Azure Function - Compute Pi Stress Test Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
Just because a service call works, doesn't mean it is correct. Many internet services incorrectly implement the rfc (dns, smtp, many more...).
-
Do you prefer to always wrap the JSON in an outer object? For example, a call to a credit card processor to get supported credit cards. Do you prefer simply the array returned:
[
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
]or the array wrapped in an outer "object":
{
"PaymentMethods": [
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
]
}If one or the other, why? Personally, I'm leaning toward the second form, which forces the Javascript writer to at least initially use the
PaymentMethodstag:let ccs = resp.PaymentMethods;Which I think improves code readability. It's also more maintainable IMO, as perhaps other tags at some point might be added -- one simple thing that comes to mind is a flag that indicates whether ACH is supported (mind you, these are all concrete examples of the general question of JSON tags):{
"PaymentMethods": [
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
],
"SupportsACH": true
}Using an outer object wrapper doesn't break the code if additional JSON elements are added later. So...thoughts? Marc
Latest Article - Azure Function - Compute Pi Stress Test Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
Definitely #2, especially if it's returned from a
GETrequest: 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
-
Do you prefer to always wrap the JSON in an outer object? For example, a call to a credit card processor to get supported credit cards. Do you prefer simply the array returned:
[
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
]or the array wrapped in an outer "object":
{
"PaymentMethods": [
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
]
}If one or the other, why? Personally, I'm leaning toward the second form, which forces the Javascript writer to at least initially use the
PaymentMethodstag:let ccs = resp.PaymentMethods;Which I think improves code readability. It's also more maintainable IMO, as perhaps other tags at some point might be added -- one simple thing that comes to mind is a flag that indicates whether ACH is supported (mind you, these are all concrete examples of the general question of JSON tags):{
"PaymentMethods": [
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
],
"SupportsACH": true
}Using an outer object wrapper doesn't break the code if additional JSON elements are added later. So...thoughts? Marc
Latest Article - Azure Function - Compute Pi Stress Test Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
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
-
Do you prefer to always wrap the JSON in an outer object? For example, a call to a credit card processor to get supported credit cards. Do you prefer simply the array returned:
[
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
]or the array wrapped in an outer "object":
{
"PaymentMethods": [
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
]
}If one or the other, why? Personally, I'm leaning toward the second form, which forces the Javascript writer to at least initially use the
PaymentMethodstag:let ccs = resp.PaymentMethods;Which I think improves code readability. It's also more maintainable IMO, as perhaps other tags at some point might be added -- one simple thing that comes to mind is a flag that indicates whether ACH is supported (mind you, these are all concrete examples of the general question of JSON tags):{
"PaymentMethods": [
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
],
"SupportsACH": true
}Using an outer object wrapper doesn't break the code if additional JSON elements are added later. So...thoughts? Marc
Latest Article - Azure Function - Compute Pi Stress Test Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
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 -
Do you prefer to always wrap the JSON in an outer object? For example, a call to a credit card processor to get supported credit cards. Do you prefer simply the array returned:
[
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
]or the array wrapped in an outer "object":
{
"PaymentMethods": [
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
]
}If one or the other, why? Personally, I'm leaning toward the second form, which forces the Javascript writer to at least initially use the
PaymentMethodstag:let ccs = resp.PaymentMethods;Which I think improves code readability. It's also more maintainable IMO, as perhaps other tags at some point might be added -- one simple thing that comes to mind is a flag that indicates whether ACH is supported (mind you, these are all concrete examples of the general question of JSON tags):{
"PaymentMethods": [
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
],
"SupportsACH": true
}Using an outer object wrapper doesn't break the code if additional JSON elements are added later. So...thoughts? Marc
Latest Article - Azure Function - Compute Pi Stress Test Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
do you prefer C# method to return
List<T> GetSomeData<T>()orT 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!
-
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
-
Do you prefer to always wrap the JSON in an outer object? For example, a call to a credit card processor to get supported credit cards. Do you prefer simply the array returned:
[
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
]or the array wrapped in an outer "object":
{
"PaymentMethods": [
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
]
}If one or the other, why? Personally, I'm leaning toward the second form, which forces the Javascript writer to at least initially use the
PaymentMethodstag:let ccs = resp.PaymentMethods;Which I think improves code readability. It's also more maintainable IMO, as perhaps other tags at some point might be added -- one simple thing that comes to mind is a flag that indicates whether ACH is supported (mind you, these are all concrete examples of the general question of JSON tags):{
"PaymentMethods": [
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
],
"SupportsACH": true
}Using an outer object wrapper doesn't break the code if additional JSON elements are added later. So...thoughts? Marc
Latest Article - Azure Function - Compute Pi Stress Test Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
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.
-
Do you prefer to always wrap the JSON in an outer object? For example, a call to a credit card processor to get supported credit cards. Do you prefer simply the array returned:
[
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
]or the array wrapped in an outer "object":
{
"PaymentMethods": [
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
]
}If one or the other, why? Personally, I'm leaning toward the second form, which forces the Javascript writer to at least initially use the
PaymentMethodstag:let ccs = resp.PaymentMethods;Which I think improves code readability. It's also more maintainable IMO, as perhaps other tags at some point might be added -- one simple thing that comes to mind is a flag that indicates whether ACH is supported (mind you, these are all concrete examples of the general question of JSON tags):{
"PaymentMethods": [
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
],
"SupportsACH": true
}Using an outer object wrapper doesn't break the code if additional JSON elements are added later. So...thoughts? Marc
Latest Article - Azure Function - Compute Pi Stress Test Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
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.
