I want to write an application in Java that will communicate with Google App Engine app written in Go by sending and receiving dynamic data. The data is not human readable (as in, not ASCII, Unicode or the like) and ranges from a couple bytes to about 1MB.
I am wondering if it is possible to send such data to and from GAE using Post method directly, or is it better to just encode it as a hex dump and transfer is at text (thusly increasing its size a couple times)?
Yes, this is possible, of course. Just like an HTTP response, an HTTP request can contain a payload of any sort (unless it's a GET or other method that doesn't permit a body); just set the content-type appropriately and send the data in the body of the HTTP request.
If people can POST 10mb photos to Facebook, then I don't see why you can't do that with your data :)
Related
I am doing a simple HTTP GET request and the response is a video. Since video is too big I cant directly read the data. Is there a work around to know how can I confirm that the content is available. Currently I am only checking for HTTP 200 OK status, I also want to read the content whatever it might be??
Are you sure that you need to stream video over TCP?
If you are sure, look at MJPEG, it is simply sequence of jpeg images with headers, that you can send over http.
Also you can implement your own frame based video streaming protocol
Currently I am sending images between an IOS app and Java web service as Strings - is there a better way to do this and if so what method is it - the Strings to represent images are huge and its quite hard to manage.
Thanks
If the image implementation you're using is serializable, serialize it.
I understood that you are currently using BASE64 encoded images being represented as strings, correct?
This approach is reasonable for small binaries/images and also to avoid many individual calls for each image in case of an list of images for example.
Anyway - a proper way would be to use a POST or PUT request to send an image to a Java web service in form of an x-www-form-urlencoded request. This is similar to what you do in a typical upload form.
Look at the example in this answer:
Send image to server as binary data
For the download of an image you can use a GET NSURLRequest (include required headers, authentication or other information to the request) and convert the received NSData to an image.
[UIImage imageWithData:dataReceivedFromURLRequest];
Or directly create the NSData for simple http requests like this and convert it to an image:
NSData *urlData = [NSData dataWithContentsOfURL:[NSURL URLWithString:#"http://my-web-service/image.png"]];
On the server side you could create an image REST endpoint using JAX-RS for example.
Please note that frameworks like AFNetworking help a lot providing convenient ways sending and receiving image/binary data.
Can someone explain to me what is actually the need to Url-encode
data sent in the body part of http requests when using
content-type: application/x-www-form-urlencoded
thanks
By "the need", do you mean "the purpose"?
If you're after the purple - it is simply there to tell the server what to expect: URL-encoded key=value pairs. It also allows the server to know what is not coming its way - the likes of multipart/form-data!
This allows the server to unambiguously know how to read incoming data.
The data is sent as one header (this is also why it has a size limit). As such, you definitely want to avoid stuff like: newlines, colons. In addition to this, you definitely want to escape = in data, so that it doesn't mess with the key=value structure. You also want to escape & for the same reason. URL-encoding does all that - so it only makes sense that whoever designed the HTTP protocol went for it!
There are multiple ways to send data to the server in a POST request; URL Encoded data is just one of several possible formats.
The client and server have to agree on the format of data in the POST body. URL Form encoded data is the easiest to use because of its universal support. Browsers support it natively. Every programming language allows you to read url encoded post parameters using a familiar syntax.
But of course, there is no need to use url form encoded. You can as easily send json or xml encoded POST body. As long as the client and server are in sync, you can even create a totally different encoding and use it.
What is the best practice if you are implementing web services that will send and receive large files to/from clients. Normally we are sending JSON objects, but it could be problematic if we include large data payload inside of the JSON objects. We need to provide JSON data as well as a payload, anyone have experience with something similar?
You could embed links to the raw data in your JSON responses. For example:
{
title: 'A Really Big File',
date: '2011-11-11',
file: 'http://example.com/really_big_file.xls'
}
That way you can allow clients to decide whether or not they want to dereference the big file or not.
Base64 is a very inefficient way of doing this, but universal. You could send your files using HTTP Post-request with special parameter "multipart/form-data".
I don't know a lot about this area so please excuse me if my question is vague or stupid.
I have a webpage which uses javascript and AJAX to display live data. Every few seconds, a request is made and a JSON response is returned and the data on the webpage is updated.
What I want to do is create a program in Java that will basically capture every response and interpret the data. I have found libraries which handle the JSON format already. However, I don't know how to get the response using Java.
So for example, a live news feed. I would like to log the data as it appears.
Thanks
Basically what you need to do is make an HTTP GET request to the page that hosts the JSON. You can do this by using a Java HTTP client. The one in the link is from Apache Commons but I believe there is actually one built into Java that is relatively straight-forward to use. When you make a request, it will return a result object that you can then use to access the response data and information such as response headers, etc.