{ members: [
[
{
c1: [{fft: 5,v: 'asdead#asdas.com'}],
c2: [{fft: 9,v: 'tst'}],
c3: [{sft: 1,v: 'Corporate Member'}]},
{
c1: [{fft: 5,v: 'asdk#asda.com'}],
c2: [{fft: 9,v: 'asd'}],
c3: [{sft: 1,v: 'Company'}]}
...etc
What is this JSON format? The full version is here.
It just doesn't look like any other JSON I've seen. I would be very thankful for a pointer in the right direction to parse this. So long as it's not just regex it, which I'm sure is possible but not something I can accomplish.
This appears to be the result of an ASP .NET web service based on the .asmx in the URL. What looks non-standard to me (based on the http://www.json.org/ definition) is the lack of double-quotes around the keys, and single-quotes instead of double-quotes wrapping the string values. E.g. v: 'asdk#asda.com' should be "v": "asdk#asda.com". I believe this is object literal notation of JavaScript (http://www.dyn-web.com/tutorials/obj_lit.php) rather than strict JSON, which is itself a subset of object literal notation.
How you choose to parse it could depend on what language/platform constraints you have, but I believe JavaScript will handle it. For an example, see this JSON/JavaScript code on Google Code Playground: http://code.google.com/apis/ajax/playground/#json_data_table. It constructs a JSON object using object literal notation for its visualization service.
Judging by this question and its followup on the Wild Apricot forums, you're poking at an undocumented tool primarily intended for internal use. Your best bet is to leave it alone. Your second-best bet is to hack at an existing parser in whatever language you are handling this with so that the parser tolerates unquoted keys.
You would probably be best off using a standard JSON library to parse it. A full list, organized by platform, is available at the json.org site.
That's not JSON. It actually looks like a lua source code encoding of the data. But if it is undocumented, it could be anything, so you're probably not going to be able to handle it reliably.
Related
Chrome Developer Console is console.loging this:
Your JSON sent is>> {yourVariable: "nothing yet"}
So i know the value "nothing yet" in the {yourVariable: "nothing yet"} JSON object is a string. But how do I know the type of the key yourVariable?
Is there a way how to find that out using the Chrome console only?
All object keys are strings with quotes or without quotes. Try this way to see it. May be you are confused with console print because console print it without quotes and we usually write with quotes.
var jsonObj = {person:"me","age":"30", 123:"123"};
Object.keys(jsonObj).forEach(function(key){
console.log(typeof key)}
);
I have a slightly different take on this question which does not invalidate the comments or answer that you received, but is worth considering.
Because you are talking about JSON, there is no intrinsic datatype in your example. As stated on the JSON.org page:
JSON (JavaScript Object Notation) is a lightweight data-interchange
format. It is easy for humans to read and write. It is easy for
machines to parse and generate.
The point is, that there is a difference between JSON, which is a representation of javascript objects, arrays etc., and variables of those types in javascript.
If you remind yourself that JSON is a form of serialization it makes a lot more sense. Javascript objects for example, can include functions, but a javascript function is not a portable thing, so in rendering some JSON from a javascript object, it is up to the language creating the JSON to do whatever it it needs to in order to convert the data it needs to represent, and that may include simplification and in many cases removal of elements that are incompatible JSON.
The other thing to keep in mind, is that all modern languages have functions or libraries that can parse JSON and turn them into variables or objects that work in those languages. In doing so, they have arguments that can completely change the way the JSON is converted back into instance variables.
For example, in PHP you can choose to have the JSON create one or more PHP objects, or an array of php variables.
In summary, JSON doesn't have variables with datatypes at all. It is a representation of data, that is portable across languages, but the languages must decode the JSON and create objects or variables that are valid in their own runtime.
I'm a Frontend Engineer, our team is switching many of our old services to micro services written in clojure. The main issue I'm seeing is that clojure naming conventions prefer hyphens to-separate-words in variable names. This means if you straight map variables into JSON any JS consumer would need to access this data using bracket notation e.g. response['to-separate-words']. This is obviously not ideal. I thought this would be a easy best practice to lookup but I've been looking for an hour and it seems like all the docs I read avoid this issue but using single words. Has anyone else dealt with this.
You might use camel-snake-kebab library which supports most of the combinations. You can plug it in into most of the JSON libraries for Clojure (cheshire, cli-json, data.json - as mentioned by Elogent) as they usually have an option to provide a function for handling property name mangling.
For example with cheshire:
Generate JSON with camel case property names:
(cheshire.core/generate-string {:my-clojure-key "abc"}
{:key-fn camel-snake-kebab.core/->camelCaseString})
Result:
{"myClojureKey":"abc"}
Parse JSON to get map with kebab case keys:
(cheshire.core/parse-string "{\"myClojureKey\":\"abc\"}"
camel-snake-kebab.core/->kebab-case-keyword)
Result:
{:my-clojure-key "abc"}
There is also an example for data.json in camel-snake-kebab readme.
I'm confused what free-form JSON means. Does it mean you can put any types as values in {}?
I thought all JSON are like that (i.e. {'hi':123, 'abc':{'d':[1,2,3],'e':'yay'}}).
So what does free-form JSON mean. Is this a redundant term? Is there such thing as non-free-form JSON?
What you have just posted looks like a JavaScript object, but it is not valid JSON. JSON has some very strict rules, such as all strings must be in double quotes. See JSON.org
There's no such thing as "free-form"/"non-free-form" JSON as every valid JSON-string must be formatted according to the specific rules mentioned on JSON.org.
It's possible that "free-form" JSON is JSON that has been generated "by hand" meaning that you typed it out manually (error prone). Most languages either have built-in methods, or libraries that are available, that turn native data structures (like multi-dimensional arrays) into valid JSON.
PHP, for instance, has a native method called json_encode.
Is it advisable or not in a RESTful web service to use JSON literal values (string / number) as input parameter in the payload or in the response body?
If I have an endpoint PUT /mytodolist is it OK for it to accept a JSON string literal value "Take out the rubbish" in the request payload (with Content-Type=application/json) or should it accept a JSON object instead ({"value":"Take out the rubbish"})?
Similarly, is it fine for GET /mytodolist/1 to return "Take out the rubbish" in the response body or should it return a proper JSON object {"value":"Take out the rubbish"}
Spring MVC to makes implementing and testing such endpoints easy, however clients have flagged this as non standard or hard to implement. In my point of view JSON literals are JSON, but not JSON objects, so I'd say it is fine. I have found no recommendations using Google.
EDIT 1: Clafirication
The question is entirely about the 'standard', if it allows this or not.
I understand the problem with the extensibility, but one can never design a fully extensible interface IMHO. If changes need to be done, we can try extending what we have in a backwards compatible way, but there will come a time when it becomes messy and an other approach is required - which is commonly handled by versioning the API in one way or another. I find it a fair point even though, because using literals as request/response body immediately becomes inextensible, while coming up with a reasonable one-attribute JSON object does not.
It is also understood that some frameworks have problems with handling JSON literals, this is the origin of this question. The tool I used happened to support this, so I thought this was all right, but the front-end library did not.
Still, what I am intending to find out right now, is if using JSON literals is according to the de-facto standard (even if it is a cornercase) or not.
I would recommend to use JSON object always. One reason is that for Content-Type application/json people expect something staring with "{" and not all frameworks will handle json literals properly. Second reason is that probably you will add some additional attributes to you list item (due date, category, priority, etc). And then you'll break backward compatibility, by adding new field.
It may be acceptable in the context of your example, but keep in mind that unambiguous interfaces are easier to use and that will encourage adoption.
For example, your interface could interpret "Take out he rubbish" as the same as {task:"take out the rubbish"}, but once you add additional properties (eg "when" or "who") the meaning of a solitary string in the request becomes ambiguous. It's inevitable that you'll add support for new properties as your interface matures.
We're adding JSON output to an existing API that outputs XML, to make MobileHTML integration much easier. However, our developer has queried the use of #attributes appearing in the JSON output.
Our original XML looks like:
<markers>
<marker id="11906" latitude="52.226578"
...
and so the JSON comes out as:
callbackname({"marker":[{"#attributes":{"id":"11906","latitude":"52.226578"
....
Our developer has stated:
"Although '#attributes' is legal JSON, it seems to break dot notation, so I can't call data.#attributes. I can call data['#attributes'], so there's a workaround, but it seems safer just to avoid the #-symbol, unless there's a good reason for it."
The XML->JSON(P) conversion is done using:
$xmlObject = simplexml_load_string ($data);
$data = json_encode ($xmlObject);
I want to make our API as easy-to-integrate as possible, and therefore to use standard stuff where possible. But we're using the native PHP json_encode function, so I'd be surprised if it's doing something non-standard.
Is use of #attributes non-standard? Is this basically just the problem that our API is a bit broken in terms of using <marker id..> rather than <marker><id> ?
The JSON standard only specifies what is and isn't valid; it doesn't set convention. There's nothing inherently wrong with using property names which aren't valid Javascript identifiers.
However, as your developer points out, this does make it slightly more awkward to use the result in JS, as it makes it impossible to use dot notation. On the gripping hand, using attributes for simple content is usually seen as "good XML" and you're using using default, built-in tools to convert from XML to JSON. I'd tend to consider that a good enough reason to leave it as it is.
If it were me, I'd look at how difficult it would be to implement a custom XML -> JSON converter. If it's simple and straightforward, go that route and avoid #attribute (it will also likely make your JSON smaller and simpler). If it's too much hassle, however, missing out on dot notation isn't the end of the world. At worst, var attr = data.marker["#attributes"]; will get around the issue.