Some questions on better practices in the formation of JSON data

[mojtabaavahdati]

There are many websites that explain what a JSON is like, but I’ve found none that explains what a JSON “should” be like. I’m talking about better practices.

To be more specific on my question: I’m requesting the data of a week(for a reservation system) using the Ajax technique and currently this is what I’m sending back(I’ve omitted some days and some times for the sake of brevity):

{
	"week": 
	[
		{
			"stamp": 1234567890,
			"dayName": "sunday",
			"date": "July 25th",
			"times": 
			[
				{
					"state": "past",
					"price": 20,
					"time-number": 1,
					"time-span": "08:00 to 09:30"
				},
				{
					"state": "free",
					"price": 40,
					"time-number": 2,
					"time-span": "09:30 to 11:00"
				},
				{
					"state": "reserved",
					"price": 30,
					"time-number": 3,
					"time-span": "11:00 to 12:30"
				}
			]
		},
		{
			"stamp": 1234561234,
			"dayName": "monday",
			"date": "July 26th",
			"times": 
			[
				{
					"state": "free",
					"price": 20,
					"time-number": 1,
					"time-span": "08:00 to 09:30"
				},
				{
					"state": "reserved",
					"price": 45,
					"time-number": 2,
					"time-span": "09:30 to 11:00"
				},
				{
					"state": "free",
					"price": 30,
					"time-number": 3,
					"time-span": "11:00 to 12:30"
				}
			]
		}
	]
}

Now my questions are:

1. This is the arrangement that makes the most sense to me. However, doesn’t it have any problems/weaknesses according to your experience? (I specially ask this because in the JavaScript side I’ve come up with writing something which is a bit long to me to fill the table fields)

2. Since all the time spans are the same for all days of week, should I still send the time-span like this(isn’t it redundant?), or I should put another key value at the end of my JSON to specify it and that would be enough?

3. What level of nested-ness is common/usual/not-weird! in a JSON arrangement?

4. Do I really need to specify that this is the “week” information at the beginning? I looked at some JSON samples on the Internet and felt like it’s needed to be there. Maybe it makes the sent data even more readable(?).

Thank you in advance.

[NOOB109]

Actually, this to me looks great. Where JSON gets in trouble is having non-standardized (bastardized) responses where you get variable and indeterminable field response where you have no idea of what to do with the random data.

In otherwords, to borrow a phrase (perhaps incorrectly), the data sent, is synchronous with an ‘expected response’, field->value approach.

I’ve had idiotic json responses where I gotta write a loop to where I have to say, figure out how many levels below the parent maximum I have to go? This is based on an outside supplied data source that was unpredictable. You’re in a good mode here, where you’re writing both the writer, and the reader at the same time.

What you’re doing is just fine imo. As long as you control the source and destination, it’s a perfect world.
:^)
PS: In the end, I would change the ‘Date’ field to something like:
‘Month’: July … Or a number like 7.
‘Day’: 26 … Delete the americanish behavior here. You need digital behavior.
‘Year’: 2018 … Anything close to the end of the year is problematic once it overlaps to 2019.
‘DayName’: Monday.
Using behavior like 26th leaves you floundering with a date like 23th… rather 23rd. A simple number is much better.
Something like that.

[SamA74]

It’s hard to say what’s best seeing just the data alone, as the best structure is dependent on the requirements of the app, what it does and what data it requires to do that.

@NOOB109

PS: In the end, I would change the ‘Date’ field to something like

Agreed, you should use standard machine readable date formats like yyyy-mm-dd which is also human readable.
Same goes for your times. I would probably split those to two separate properties, like "startTime" and "endTime" taking out the human friendly “this to that” string for something more machine readable.