I would like to send erlang terms (erlang-based back end) to the web browser. It is easy enough to encode a term on the erlang side using something like:
term_to_binary(Term)
or:
binary_to_list(term_to_binary(Term))
The problem of course is that scrambled garbage shows up on the browser end.
Question: Is there either some encoding I can use on the browser end, or more likely, some Content-Type I can accept on the browser end to unscramble this?
Thanks.
Use io_lib:format("~p",[Term]). It will produce a string representation of the erlang term which can be showed on a web page. Consider also checking out this question and its answer.
There is piqi that provides extensive mapping mechanisms between .piqi (its record definition language), json, xml and protobuf. It's a really cool tool, that we use all the time to map between all of these formats.
Typically when I build something (in Erlang) that needs to provide some sort of data to something else, I start with a piqi definition file that defines the structure. The piqic compiler generates Erlang record definitions and conversion code to do conversions easily.
Highly recommended, but it might be overkill for what you're doing.
Encode it with base64. Get it via ajax, then decode either with native window.atob or any of numerous available libs.
If it is for a web browser, I would go for a Json string, it's unicode and browsers support it nativaly.
Maybe consider Json and do something like this for strings:
1> HelloJerome = "Hello Jérôme".
"Hello Jérôme"
2> HelloJeromeBin = list_to_binary(HelloJerome).
<<"Hello Jérôme">>
3> HelloJeromeJson = << <<"{\"helloJerome\":\"">>/bits, HelloJeromeBin/bits, $\", $} >>.
<<"{\"helloJerome\":\"Hello Jérôme\"}">>
In the browser console:
jerome = JSON.parse('{\"hello\":\"Hello Jérôme\"}')
Now
jerome.hello == "Hello Jérôme"
There are some good lib out there ejson or mochijson2 are the classic ones but ktuo or ...
Related
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.
While working on scala REPL with Play Json support(play.api.libs.json), it possible to specify that all REPL output of JsValues should be automatically formatted?
e.g. By specifying another formatter via implicits
I know Json.prettyPrint does JSON pretty on Play, I was interested to know if there is a mechanism, either in play.json to specify a formatter to be used on toString, or if there is a Scala 2.10 construct I can use to automatically wrap every call with minimal or preferably no overhead to the calls.
Probably in Play 2.1+ with Scala there Json.prettyPrint should work (can't confirm now, have no any Scala project atm, but doc says that).
On the other hand, if only destination for prettifying the JSON is possibility to check it 'with your own eyes' I'd rather suggest to leave it in compressed form, and then use some browser plugin to display it in prettified version, it also validates the code, allows to fold the sections etc. ie this one: https://chrome.google.com/webstore/detail/jsonview/chklaanhfefbnpoihckbnefhakgolnmc
What's most important you still save your transfer as just source JSON is still compressed ;)
Recently came across the term JSONC in a YouTube API. I browsed the Web, but found nothing much about it. Can someone explain whether these two are the same or different?
There is also jsonc aka "JSON with comments", created by Microsoft and used by Visual Studio Code. The logic for it can be found here, alas without exhaustive specification (though I'd like to be proven wrong on this).
On top of that there is this project with an actual specification which is also called jsonc, but also does far more than just adding comments.
While there definitely is a use for these technologies, some critical thinking is advised. JSON containing comments is not JSON.
JSON-C seems to just be a variation of JSON mainly targeted at C development. I.e., from the open source docs, "JSON-C implements a reference counting object model that allows you to easily construct JSON objects in C, output them as JSON formatted strings and parse JSON formatted strings back into the C representation of JSON objects."ref^1
From the YouTube API perspective (specifically, version 2, not the new version 3), The JSON-C response is just a condensed version of the JSON response (removing "duplicate, irrelevant or easily calculated values").ref^2
Why would the JSON response have "duplicate, irrelevant or easily calculated values" values anyway? Because it is converting the original ATOM XML format directly to JSON in a loseless conversion. You can find out more details here.
However, I would suggest using version 3 of the YouTube Data API. It is much easier to use. =)
JSONC is an open-source, Javascript API created by Tomás Corral Casas for reducing the size of the amount of JSON data that is transported between clients and servers. It uses two different approaches to achieve this, JSONC.compress and JSONC.pack. More information can be found on the JSONC Github page:
https://github.com/tcorral/JSONC
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.
{ 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.