With OkHttp we can make HTTP request then get response from server:
OkHttpClient client = new OkHttpClient();
Request request = new Request.Builder()
.url(url)
.build();
Response response = client.newCall(request).execute();
Then with Gson lib convert response to object we need.
This is from Square/OkHttp doc:
Its request/response API is designed with fluent builders and
immutability. It supports both synchronous blocking calls and async
calls with callbacks
I read from Stackoverflow:
Retrofit uses OkHTTP automatically if available.
So my questions are:
What, exactly, is Retrofit for?
What Retrofit can do that OkHttp cannot?
I think OkHttp and Gson solve the request API problem,
but what problem does retrofit solve for us?
with OkHttp we can make HTTP request then get response from server... then with Gson lib convert response to object we need
Note that in your code snippet, you skipped two notable steps: generating the URL and actually parsing the JSON using Gson.
So my question is what is exactly Retrofit for?
It is for generating the URL (using type-aware generated code tied to your specific REST API) and actually parsing the JSON using Gson. In other words, it does what you skipped in your code snippet.
Also, for certain types of REST operations (e.g., POST), it helps a bit in assembling what to submit (e.g., generating the encoded form).
By definition, you do not need to use Retrofit. Retrofit is computer code, written by computer programmers. Somebody else could write code to do what Retrofit does.
why Retrofit use OkHttp
Retrofit needs to perform HTTP operations. It uses OkHttp where available, for all that OkHttp provides: HTTP/2 and SPDY support, pluggable interceptors, etc.
You should use retrofit if you are trying to map your server API inside your application (type-safing). Retrofit is just an API adapter wrapped over okHTTP.
If you want to type safe and modularise the interaction code with your API, use retrofit. Apart from that, the underlying performance, request defaults, etc of okHTTP and Retrofit are the same.
Also I would recommend listening to this podcast from Jesse Wilson (developer of major android HTTP clients), where he talks in-depth of the history of development of Apache HTTP client, HTTPURLConnection, okHTTP and Retrofit.
Retrofit vs. OkHttp
The reason is simple: OkHttp is a pure HTTP/SPDY client responsible for any low-level network operation, caching, request and response manipulation, and many more. In contrast, Retrofit is a high-level REST abstraction build on top of OkHttp. Retrofit 2 is strongly coupled with OkHttp and makes intensive use of it.
OkHttp Functions: Connection pooling, gzipping, caching, recovers from network problems, sync, and async calls, redirects, retries … and so on.
Retrofit Functions: URL manipulation, requesting, loading, caching, threading, synchronization... It allows sync and async calls.
Retrofit is basically architecture above the OKHTTP, it internally uses OkHttp to make any request , earlier in jave if we want to make any request we have HTTPUrl connection or HTTPS Url connect know retrofit okHttp handles everything ( it divides into packages it marks headers )for us if we need to send some information .
Retrofit is a rest client that is based on restful principle .
->OkHttp is a an HTTP client, which supports HTTP/2 and SPDY.
->Retrofit is a type safe HTTP client for android and java
->OkHttp depends on Okio.
->Retrofit depends on OkHttP,
so Retrofit is basically a wrapper on OKHTTP ,it uses when necessity and can easily manage connect timeout and read timeout just using it’s methods and also adds Interceptor.
Hope I answered !!! happy coding!!!!
for more information refer https://square.github.io/retrofit
OkHttp: An open source HTTP client. HTTP is the way modern applications network. It’s how we exchange data & media. Doing HTTP efficiently makes your stuff load faster and saves bandwidth; Retrofit: A type-safe HTTP client for Android and Java. Retrofit turns your HTTP API into a Java interface.
OkHttp and Retrofit can be primarily classified as "API" tools.
Some of the features offered by OkHttp are:
• HTTP/2 support allows all requests to the same host to share a socket.
• Connection pooling reduces request latency (if HTTP/2 isn’t available).
• Transparent GZIP shrinks download sizes.
On the other hand, Retrofit provides the following key features:
• URL parameter replacement and query parameter support
• Object conversion to request body (e.g., JSON, protocol buffers)
• Multipart request body and file upload
My task is to load web site in WebView over HTTPS with unsupported by vanilla Android TLS cipher.
Right now as proof of concept I have implemented apache http client capable of doing http requests to such resources.
What is the best approach to make WebView use my custom client implementation to do all network requests?
Actually, the accepted answer is wrong. You do not get full information; what's missing are request bodies.
So you can implement GET or HEAD requests just fine, but POST requests are trickier.
I haven't seen a good solution for that yet. One I've come across uses JavaScript inserted into the page to collect the POST data, hand it to Java via a binding https://developer.android.com/guide/webapps/webview.html#BindingJavaScript and then performs the request in Java.
Unfortunately, the WebView will try to perform the same request again, so you need to add more hackery to make it work.
Since Android 5.0 (API 21+) you can use WebViewClient.shouldInterceptRequest(WebView, WebResourceRequest) to intercept web requests with full information and perform them with custom HTTP client.
Thanks #Stan for the tip.
I am writing a Java GAE app and relying on URL Fetch to send HTTP requests to other servers (see here. Up until this point, I had been using their HttpUrlConnection interface implementation in order to use the URL Fetch service. However, I am rewriting my app to use the low-level API instead of HttpUrlConnection because I want to send asynchronous HTTP requests.
My question: What is the URL Fetch low level API equivalent of HttpUrlConnection.getResponseMessage():String? Based on what I see from the low-level API javadoc for HTTPResponse, I am not sure of what method I should use. I can get the response code alright, but I'd like to read a useful message along with the code, especially for when an error occurs.
Thanks.
I am in a bit of a pickle, I need to use vosao with an Android application but I have no idea how to authenticate and use it, I have got the JSON-RPC part working by telling me if the username and password is correct but I don't know what to do from here
Vosao is a CMS for Google App Engine.
To get round this I used JSON to parse the response from the web server, then with the same HttpClient I did all my other requests :)
In building web service designed to to interact with mobile devices, I am not sure what the best approach is for implementing HTTP requests on Android.
I came across this post, which finishes by stating HttpURLConnection is the preferred method for making HTTP requests, and I have had success using the HttpsURLConnection.
When searching for answers or reading other sample code (even fairly recent posts), all seem to use DefaultHttpClient, which seems to go against the official word from Google.
I am trying to future proof my Android application as much as possible. With that in mind, is the HttpURLConnection the best choice?
If you are supporting 2.2 as well, Best approach may be to utilize both DefaultHttpClient or HttpURLConnection
if (Integer.parseInt(Build.VERSION.SDK) <= Build.VERSION_CODES.FROYO) {
// Use DefaultHttpClient here
}
else{
//use HttpURLConnection
}
Reason: HttpURLConnection is more stable after Froyo while DefaultHttpClient is less buggy in froyo and lesser version.
Ref : http://developer.android.com/reference/org/apache/http/impl/client/DefaultHttpClient.html
Android includes two HTTP clients: HttpURLConnection and Apache HTTP Client. Both support HTTPS, streaming uploads and downloads, configurable timeouts, IPv6 and connection pooling. Apache HTTP client has fewer bugs in Android 2.2 (Froyo) and earlier releases. For Android 2.3 (Gingerbread) and later, HttpURLConnection is the best choice. Its simple API and small size makes it great fit for Android. Transparent compression and response caching reduce network use, improve speed and save battery. See the Android Developers Blog for a comparison of the two HTTP clients.
It really matters which version of Android you are using. Take a look at http://android-developers.blogspot.com/2011/09/androids-http-clients.html for some guidance from Google.
DefaultHttpClient is at a higher level of abstraction than HttpUrlConnection. Either one should be fine based on your needs. If you dont need the control of HttpUrlConnection, stick with the DefaultHttpClient.