JSON responses -- what's your preference?
-
The outer object is important because even if currently there aren't any extra data items, such as the ACH you mentioned, yet, inevitably there will be and this could cause a failure in the simpler case while being handled smoothly with an outer object wrapping things up nicely. :-D Having said that, many past members of projects I have worked on didn't get the memo... :sigh:
- I would love to change the world, but they won’t give me the source code.
Forogar wrote:
inevitably there will be and this could cause a failure in the simpler case while being handled smoothly with an outer object wrapping things up nicely.
My thoughts as well.
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
PaymentMethods
tag: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
PaymentMethods
tag: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
PaymentMethods
tag: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
PaymentMethods
tag: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
PaymentMethods
tag: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
PaymentMethods
tag: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
PaymentMethods
tag: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
PaymentMethods
tag: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
PaymentMethods
tag: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
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
-
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
PaymentMethods
tag: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
PaymentMethods
tag: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
PaymentMethods
tag: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
PaymentMethods
tag: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.