Can a json file contain more than one object?
For example, can the content of a json file be two objects as the following?
{"firstName":"John", "lastName":"Doe"},
{"firstName":"Anna", "lastName":"Smith"}
Some experienced software engineer said that a json file could only contain one object, although other objects could be nested in the object.
Thanks.
That doesn't look much like json, but yes, you can totally have an array of objects in json file. Something like this in your case:
[{"firstName": "John", "lastName": "Smith"},
{"firstName": "Jane", "lastName": "Doe"}]
A json file may either contain a single object in (which can be complex, with many nested keys) or an array of such objects. It's either curly braces or square brackets on the outside.
Yes.
You can have:
JSONObject = {
ObjectOne: {
property1: value1
},
ObjectTwo: {
property1: value2
},
someProperty: value3,
....
}
EDIT: You can also have an array of objects if that suits you better.
Related
Can we write json key with space like first name?
Below is the sample json:
[
{
"first_name": "James"
},
{
"first_name": "Tom"
}
]
Yes, you can, it is valid RFC 8259, however it will make more difficult to use in some languages, for example in PHP you want be able to use the arrow operator to access the data.
This obviously won't make this JSON not valid.
Here is the desired schema and json for illustration purpose. Please see the link below.
JSON Schema and JSON
{
"id": "123" ,
"ts": "1234567890",
"complex_rules":
[
{
"type":"admin",
"rule":{
"rights":"all",
"remarks": "some admin remarks"
}
},
{
"type":"guest",
"rights": "limited"
},
{
"type":"anonymous",
"rights": "blocked"
}
]
}
The 'complex_rules' is an array of json object:
With type either be a : "admin", "guest", "anonymous" and the 'type' attribute is MANDATORY.
Each object in array can have its own structure, but the type can be either of: "admin", "guest", "anonymous" only. No other type attribute is acceptable.
The conditions to evaluate:
The type of object in the array cannot re-occur in the array. (I know this seems to be not possible, so we can ignore this)
If attribute "rights" in the {type=admin object} with any value, then we cannot have "rights": "limited" or any value in {type=guest object}. The JSON Schema validation must complain about this.
Another twist, either object {type":"guest"}or {type":"anonymous"} can exist. Both types cannot coexist along with other types.
----Update
The above link is the solution this question.
In regards to 1 and 2:
You need to use a combination of if, then, and not keywords to construct the logic you require with the correct level of applicability.
In regards to 3:
The type of object in the array cannot re-occur in the array. (I know
this seems to be not possible, so we can ignore this)
Right, that's correct, it's not possible as of draft-7 JSON Schema.
Is there another way to track what is unmarshalled than write own reverter for each field?
I'm updating my local data based on json message and my problem is (simplified):
I'm expecting json like
{ "items": [ { "id":1, "name":"foobar", "price":"12.34" } ] }
which is then unmarshaled to class TItems by
UnMarshaller.TryCreateObject( TItems, TJsonObject( OneJsonElement ), TargetItem )
My problem is that I can't make difference between
{ "items": [ { "id":1, "name":"", "price":"12.34" } ] }
and
{ "items": [ { "id":1, "price":"12.34" } ] }
In both cases name is blank and i'd like to update only those fields that are passed on json message. Of course I could create a reverted for each field, but there are plenty of fields and messages so it's quite huge.
I tried to look REST.Jsonreflect.pas source, but couldn't make sense.
I'm using delphi 10.
In Rest.Json unit there is a TJson class defined that offers several convenience methods like converting objects to JSON and vice versa. Specifically, it has a class function JsonToObject where you can specify options like for example ignore empty strings or ignore empty arrays. I think the TJson class can serve you. For unmarshalling complex business objects you have to write custom converters though.
Actually, my problem was finally simple to solve.
Instead of using TJSONUnMarshal.tryCreateObject I use now TJSONUnMarshal.CreateObject. First one has object parameters declared with out modifier, but CreateObject has Object parameter var modifier, so I was able to
create object, initalize it from database and pass it to CreateObject which only modifies fields in json message.
We are currently investigating JSON as a potential API data transfer language for our system and a question about using JSON Reference came up.
Consider the following example:
{
"invoice-address" : { "street": "John Street", "zip": "12345", "city": "Someville" },
"shipping-address": { "$ref": "#/invoice-address" }
}
According to our research, this is a valid usage of JSON Reference. We replace the instance of an object with another object containing the reference pointing to a different object using a JSON Pointer fragment.
Now, a JSON Reference always consists of a key-value pair and thus has to be enclosed in an object. This would mean that in order to reference a non-object data type (e.g. the zip and city strings in the example above) you would have to do the following:
{
"invoice-address" : { "street": "John Street", "zip": "12345", "city": "Someville" },
"shipping-address": { "street": "Doe Street", "zip": { "$ref": "#/invoice-address/zip" }, "city": { "$ref": "#/invoice-address/city" } }
}
Even though the JSON Pointers now correctly point to string values, we had to change the data type of zip and city from string to object, which make them fail validation against our JSON Schema, because it declares them as strings.
However, the JSON Reference draft states:
Implementations MAY choose to replace the reference with the referenced value.
Does that mean that we are allowed to "preprocess" the file and replace the JSON Reference object with the resolved string value before validating against the JSON Schema? Or are references limited to object types only?
Thanks to anyone who can shed some light onto this.
I wouldn't expect most validators to resolve JSON References before validation. You could either:
resolve JSON References before validation
adapt the JSON Schemas to allow for JSON Reference objects in certain places
Personally, I think the first option is much neater.
You could end up with circular references I suppose - I don't know which validator/language you're using, but tv4 can definitely handle it.
For some endpoints SimpleGeo.com returns something like this:
{
"geometry":{
"type":"Point",
"coordinates":[
-122.421583,
37.795027
]
},
"type":"Feature",
"id":SG_5JkVsYK82eLj26eomFrI7S_37.795027_-122.421583#1291796505,
"properties":{
"province":"CA",
"city":"San Francisco",
"name":"Bell Tower",
"tags":[],
"country":"US",
"phone":"+1 415 567 9596",
"href": http://api.simplegeo.com/1.0/features/SG_5JkVsYK82eLj26eomFrI7S_37.795027_-122.421583#1291796505.json,
"address":"1900 Polk St",
"owner":"simplegeo",
"postcode":"94109",
"classifiers":[
{
"category":"Restaurant",
"type":"Food & Drink",
"subcategory":""
}
]
}
}
(see http://simplegeo.com/docs/api-endpoints/simplegeo-features#get-detailed-information).
Now I have a small problem deserializing the 'properties' part. If I use e.g. a type of Dictionary it converts it to a nice dictionary, but the 'classifiers' value is just one {} string.
Is there any way to tell json.net to deserialize sub-arrays into yet another Dictionary etc etc? Basically there's an amount of plain key/values in that return, but I do know that there might be more than just that 'classifiers' sub-array (see the 'tags'), and maybe the depth goes even further in the values...
So basically what I was wondering is, how do I properly deserialize the properties part? Any suggestions? I don't mind writing my own JsonConverter, but maybe there is already a way that works without it.
I've found a solution for a similar question over here:
Json.NET: Deserializing nested dictionaries.
It uses a custom JsonConverter and I don't see a way to do without it.