I'm developing an Android application which communicates with (our own) API. It was meant to use the API in manipulative requests with the request method POST and at not-manipulative requests GET (as it should be in RESTful applications).
To authenticate or add parameters to the request, the HTTP request body has been used (in both GET and POST requests). (YES, it is possible and allowed to add a request body to GET requests per HTTP definition (see e.g. this post)). The post generally says, that it is possible to add a request body, but the server may not use it during the request.
The problem is, that the request method is always set to POST, no mather if I set it to GET anywhere during the connection configuration, even if the getRequestMethod does return GET after setting it to GET via setRequestMethod("GET").
The android application uses the HttpsURLConnection (which is an extended class from HttpURLConnection, so it should behave similary).
By calling these methods, a request body will be attended:
https.setDoInput(true);
OutputStream os = https.getOutputStream();
os.write(outputInBytes);
os.close();
And by calling https.setRequestMethod("GET"), the request method should be set to GET.
After a little investigating, the line OutputStream os = https.getOutputStream(); sets the request method to POST, afterwards I set it to GET again and it remains GET till the end of the connection (as returned by https.getRequestMethod())
But in the end the server receives the request with the request method POST.
So my specific questions are:
Is there a possible workaround / solution for this problem?
Is it really that bad to add a request body to a GET request?
Currently I have just set all requests to POST, so there is no problem with it (and I wouldn't have a problem to leave it this way, but for several reasons I would like to know for sure that there is no other way to fix this problem)
Edit: The documentation of the getOutputStream() method says:
The default request method changes to "POST" when this method is called.
By default the HttpURLConnection is a GET Method (getDoInput() is true by default).
If you use setDoOutput(true) it will become a POST method.
If you need another method (PUT, DELETE, etc...) then you will use setRequestMethod(string).
And of course you have to select the method you want before the connect() method
Related
I am trying to examine the headers of a response from an API call made via Retrofit 2.0.2 before actually downloading the content.
My API interface looks like the following:
#Headers({"Accept: application/json", "Origin: http://www.example.com"})
#HEAD("profiles")
Call<Void> getProfileHeaders(#Field("puids") String puid);
Please note that the API call requires me to specify in the body a field called puids=%{UUID} list of UUIDs in order to return a response.
If I would like to download the data without examining the headers first, I would just call an interface like this:
#Headers({"Accept: application/json", "Origin: http://www.example.com"})
#FormUrlEncoded
#POST("profiles")
Call<String> getProfile(#Field("puids") String puid);
Now the issue is that when I try to use the getProfileHeader() endpoint, I get the following RuntimeException:
java.lang.IllegalArgumentException: #Field parameters can only be used with form encoding. (parameter #1)
In order to use the #Field parameters (as I suppose a POST method would normally would do if required), I would have to explicitly specify that I use #FormUrlEncoded, but I can't make a #HEAD call with that.
I am a bit puzzled how could I achieve what I want and what am I missing?
Basically I would like to know how can I examine a retrofit call's response headers before downloading the actual body, of an API endpoint that requires field parameters?
Cheers!
Ok, I just realized that my confusion originates from a couple of misunderstandings:
#HEAD is an HTTP method to usually verify the hyperlinks validity and the server's response to a GET call. It does not work with POST request and it is theoretically incorrect.
Taken from RFC2616 of the HTTP/1.1 definitions:
The HEAD method is identical to GET except that the server MUST NOT
return a message-body in the response. The metainformation contained
in the HTTP headers in response to a HEAD request SHOULD be identical
to the information sent in response to a GET request. This method can
be used for obtaining metainformation about the entity implied by the
request without transferring the entity-body itself. This method is
often used for testing hypertext links for validity, accessibility,
and recent modification.
The response to a HEAD request MAY be cacheable in the sense that the
information contained in the response MAY be used to update a
previously cached entity from that resource. If the new field values
indicate that the cached entity differs from the current entity (as
would be indicated by a change in Content-Length, Content-MD5, ETag or
Last-Modified), then the cache MUST treat the cache entry as stale.
When making a POST request by definition we already calculated the response server-side and taken the time to download the body in consideration.
One of the function's of the POST method, as defined in RFC2616 is:
Providing a block of data, such as the result of submitting a form, to a data-handling process;
Hence verifying the header in order not do download the body beats the purpose of this.
As mentioned by #Radek above, using interceptors on GET request to modify and/or examine requests on the fly would do the work, but at that point we could also initiate a HEAD method request.
The solution to this problem would be to better align to the standard definitions defined in RFC2616 by making changes on the server-side to instead of returning block of raw data as a POST response, make it to return a resource that would be than called in a GET/HEAD request then. All just refactor the service call to use GET instead of POST.
Okhttp which is used by retrofit has Interceptors which let you modify or examine requests on the fly. Check out the github documentation
So basically right now my app is configured to use https because in the "release" it will use a self signed certificate and obviously also use Https.
My current testsystem (few more features) doesn't use https but http instead. I thought it would be kinda nice to have some type of method to check whether the given URL is Http or Https and depending on the result create the right URLConnection.
My current problem is that I don't know what the method should exactly look like. I thought about using if-statements in the methods which connect to my server but there might be a better solution.
Help would be appreciated.
How about this:
URLUtil.isHttpUrl(String url)
URLUtil.isHttpsUrl(String url)
See also: http://developer.android.com/reference/android/webkit/URLUtil.html
If you don't want to do a manual check you can use a 3rd party library like this one: http://square.github.io/okhttp/ which allows you a simple:
Request request = new Request.Builder().url(url).build();
Response response = new OkHttpClient().newCall(request).execute();
I am having the following API call:
http://rollout.gr/api/?query={%22search%22:%22places%22,%22page%22:1}
This API call is executed correctly in my browser. But when I use a DefaultHttpClient to execute this url in my Android application, I get a null response.
I suppose the problem is the JSON data in the HTTP url. Thus, I would like to ask which is the proper way to handle such url in an Android application?
Thanks a lot in advance!
The accolades aren't valid URL characters. The browser is userfriendly enough to automatically URL-encode them, but DefaultHttpClient isn't. The correct line to use from code is:
http://rollout.gr/api/?query=http://rollout.gr/api/?query=%7b%22search%22:%22places%22,%22page%22:1%7d
Note the encoding for the accolades (%7b, %7d).
Your problem may be the strictmode here.
I recommend to do http request in threads or asynctasks. strictmode doesnt let app do http reauest in uithread. maybe your console shows a warning and you get null from http response because of this.
This project may solve your problem:
http://loopj.com/android-async-http/
Not knowing your particular HTTP initialization code, I'm going to assume you didn't provide an explicit JSON accept header. A lot of REST endpoints require this.
httpget.setHeader("Accept", "application/json");
I want to know whether it is possible to create an Android application to communicate with a session bean and invoke a method. if so can anybody explain how? or else can i invoke that method in the EJB with a JSP/servelet and call the JSP/Servelet with Android clients.. examples are highly appreciate
Thanks !!!
It is possible to communicate with Servelet in Android using HttpClient, HttpPost and HttpGet classes in android..
It is in theory relatively simple. Servlets can be configured by web.xml or #WebServlet annotation to get executed on a certain request URL. On a HTTP GET request the doGet() method will be executed. On a HTTP POST request, the doPost() method will be executed. The business logic which the servlet executes can depend/rely on the presence of HTTP request parameters and/or the request URI pathinfo.
All you need to do is to fire a HTTP request with the right URL and/or the right request parameters and/or the right pathinfo to let the servlet execute the desired job.
The basic Java API offers the java.net.URL and java.net.URLConnection for this. A simple HTTP GET request can be executed as follows:
InputStream response = new URL("http://example.com/servleturl?foo=bar&bar=foo").openStream();
// ...
Firing HTTP POST requests is a bit more complex. It can be done with java.net.URLConnection as outlined in this mini-tutorial, but Android also ships with Apache HttpComponents Client which allows firing and handling HTTP requests with less lines of code and more self-explaining code.
On http://androidsnippets.org you can find a lot of examples with HttpClient.
i'm sending an http request to the google reader api and getting an unusual response code. following the documentation, i've requested an auth code and included it in the header of every request. after performing the login, and getting an auth code, i tried accessing this url, which is part of the documentation:
http://www.google.com/reader/api/0/stream/items/contents
when i send the request, i get a 411 status code, which is supposed to mean "Length Required". the length, as i've found, is supposed to be the length, in octets, of the message body. there is no message body in this request. there is only a single header, the POST parameter i="item id" and the URL itself. i tried setting the "Content-Length" header to "0" and also to "-1" to no avail.
what's really interesting is that this same code worked fine before google changed their authorization procedure. it's apparent they've changed something else...
so my question is what EXACTLY would cause a 411 response code and how can i prevent it?
This error happens only with POST and PUT request types, as these two (sort of) expect to have a request body that includes the request parameters (plain textual as well as attachments).
However as the documentation suggests, this is largely an obsolete value, and realistically the web services should handle requests without relying on Content-Length.
So it's not the problem of a request sender, but it is (I would say) a bug on the service side.
Nevertheless, setting a Content-Length (mind the proper capitalisation) request header to 0 should be the workaround.