The URL https://www.googleapis.com/freebase/v1/topic/en/alps returns a JSON string that is nicely formatted for reading. How can I tell Freebase to return the raw JSON string without all the unnecessary characters?
You can make the API request with GZIP enabled which will get rid of ALL the unnecessary bytes.
Accept-Encoding: gzip
You can also use the filter parameter to only return the property values that your app needs.
I don't think you can, but it shouldn't make a difference to any JSON parser. The whitespace isn't significant.
Related
I am trying to consume flickr api and requesting data in json format from a node.js server. I am providing nojsoncallback=1 so that returned json is not wrapped inside a jsonp callback. Here is the url http://api.flickr.com/services/feeds/photos_public.gne?format=json&nojsoncallback=1.
Json returned is not properly formatted and JSON.parse is unable to parse it. If I don't pass nojsoncallback query param and eval the response which calls jsonFlickrFeed function, it gets evaled properly and I get the object. I also notice that the Content-type header in the response is application/x-javascript; charset=utf-8. I suspect that the special characters are double escaped in returned response.
I don't want to eval, what can I do to convert the response correctly into a string and then parse it?
By the way here is the gist with simplest use case. No modules, no middlewares.
I am designing a Web API which returns JSON as the content-type, the response body could contain characters like ', ", < and >, they are valid characters in JSON. So, my question is should I do HTML encode for my Web API response body or should I leave this task to HTML client who is consuming my Web API?
No; you must not.
You must only escape data if and when you concatenate it into a structured format.
If you return JSON like { "text": "Content by X & Y" }, anyone who reads that JSON will see the literal text &.
It will only work correctly for extremely broken clients who concatenate it directly into their HTML without escaping.
In short:
Never escape text except when you're about to display it
What platform are you using? For example, Node.js, you can use restify to handle that very well. You don't need to explicitly encode the data. Therefore, please find a restful framework or component to help you out.
Recently I run into some weird issue with http header usage ( Adding multiple custom http request headers mystery) To avoid the problem at that time, I have put the fields into json string and add that json string into header instead of adding those fields into separate http headers.
For example, instead of
request.addHeader("UserName", mUserName);
request.addHeader("AuthToken", mAuthorizationToken);
request.addHeader("clientId","android_client");
I have created a json string and add it to the single header
String jsonStr="{\"UserName\":\"myname\",\"AuthToken\":\"123456\",\"clientId\":\"android_client\"}";
request.addHeader("JSonStr",jsonStr);
Since I am new to writing Rest and dealing with the Http stuff, I don't know if my usage is proper or not. I would appreciate some insight into this.
Some links
http://lists.w3.org/Archives/Public/ietf-http-wg/2011OctDec/0133.html
Yes, you may use JSON in HTTP headers, given some limitations.
According to the HTTP spec, your header field-body may only contain visible ASCII characters, tab, and space.
Since many JSON encoders (e.g. json_encode in PHP) will encode invisible or non-ASCII characters (e.g. "é" becomes "\u00e9"), you often don't need to worry about this.
Check the docs for your particular encoder or test it, though, because JSON strings technically allow most any Unicode character. For example, in JavaScript JSON.stringify() does not escape multibyte Unicode, by default. However, you can easily modify it to do so, e.g.
var charsToEncode = /[\u007f-\uffff]/g;
function http_header_safe_json(v) {
return JSON.stringify(v).replace(charsToEncode,
function(c) {
return '\\u'+('000'+c.charCodeAt(0).toString(16)).slice(-4);
}
);
}
Source
Alternatively, you can do as #rocketspacer suggested and base64-encode the JSON before inserting it into the header field (e.g. how JWT does it). This makes the JSON unreadable (by humans) in the header, but ensures that it will conform to the spec.
Worth noting, the original ARPA spec (RFC 822) has a special description of this exact use case, and the spirit of this echoes in later specs such as RFC 7230:
Certain field-bodies of headers may be interpreted according to an
internal syntax that some systems may wish to parse.
Also, RFC 822 and RFC 7230 explicitly give no length constraints:
HTTP does not place a predefined limit on the length of each header field or on the length of the header section as a whole, as described in Section 2.5.
Base64encode it before sending. Just like how JSON Web Token do it.
Here's a NodeJs Example:
const myJsonStr = JSON.stringify(myData);
const headerFriendlyStr = Buffer.from(myJsonStr, 'utf8').toString('base64');
res.addHeader('foo', headerFriendlyStr);
Decode it when you need reading:
const myBase64Str = req.headers['foo'];
const myJsonStr = Buffer.from(myBase64Str, 'base64').toString('utf8');
const myData = JSON.parse(myJsonStr);
Generally speaking you do not send data in the header for a REST API. If you need to send a lot of data it best to use an HTTP POST and send the data in the body of the request. But it looks like you are trying to pass credentials in the header, which some REST API's do use. Here is an example for passing the credentials in a REST API for a service called SMSIfied, which allows you to send SMS text message via the Internet. This example is using basic authentication, which is a a common technique for REST API's. But you will need to use SSL with this technique to make it secure. Here is an example on how to implement basic authentication with WCF and REST.
From what I understand using a json string in the header option is not as much of an abuse of usage as using http DELETE for http GET, thus there has even been proposal to use json in http header. Of course more thorough insights are still welcome and the accepted answer is still to be given.
In the design-first age the OpenAPI specification gives another perspective:
an HTTP header parameter may be an object,
e.g. object X-MyHeader is
{"role": "admin", "firstName": "Alex"}
however, within the HTTP request/response the value is serialized, e.g.
X-MyHeader: role=admin,firstName=Alex
I am writing some code to interface with a service that I do not have yet, so I am writing a simulator to attempt to de-risk some of the problems I might run into when I get a chance to integrate against the real system. The interface is basically a REST style interface that returns JSON formatted strings.
The interface specification says the JSON formatted response is returned in lieu of the standard HTTP body. It also says that responses from the server will be zlib compressed and have the "Content-Encoding: gzip" set in the header.
So I created a WCF service that provides a REST interface that returns a JSON formatted string. I now need to deal with the compression portion of the equation. To satisfy the Content-Encoding: gzip requirements, do I simply gzip the JSON string I created and return that rather than the string? Or is it more involved than that? Let me know if there is any other information that is needed here, as I am still a newbie when dealing with REST/HTTP.
Thanks so Much for your time.
You're correct. Just Gzip the JSON string and return it.
Best reference for any REST implementation is the HTTP/1.1 RFC: https://www.rfc-editor.org/rfc/rfc2616
In short: yes, it's as simple as that. The response body just needs to be the gzip-compressed version of the normal response body.
This question may have some useful information for setting up your service.
want to test my url service in browser but need to pass json format data.
I tried the below but no success:
http://locahost:8042/service/getinfo?body={"name":"H&M"}
or any tool that can be use to pass json formatted test data?
UPDATES1
I mean is to pass the json formatted data manually in browser's url address bar. Like as my example above. This is for quick testing only not for implementation.
Yes, you certainly can pass JSON in a URL Querystring. You just have to URLencode the JSON string first. As #dmn said, the data is probably better passed via POST because of GET's size restrictions.
The { and } characters are considered unsafe for unencoded use in a URL.
http://www.faqs.org/rfcs/rfc1738.html
Probably putting it in the GET won't be a good idea, since url parameters have a limit of 256 characters. It would be better if you use POST and put the JSON in the body and after that you can parse it using Jackson for example or gson ... and get the result as an object.
Yes you can Add Extension to chrome web-browser called 'Advance rest Client' and change contain header to application/json and make json object and post in pay load then hit send bottom it works for json object
enter image description here
This is how I am doing in my web service, I am passing a json and within the service I manage it.
Just do a URL query like this:
http://locahost:8042/service/getinfo?name=h%26m
%26 is the encoding of &