Geonode logo
Geonode Team

Geonode Team

Güncellenme: 7 Ekim 2026

Yayınlanma: 2 Eylül 2026

Java'da OkHttp: Başlangıç Kılavuzu

OkHttp, çoğu JVM ve Android projesinin sonunda kullandığı HTTP istemcisidir ve yeni başlayanların dikkatini çeken iki tasarım kararı vardır: istemcinin paylaşılması amaçlanmıştır ve yanıt gövdeleri kapatılmalıdır. Bunları doğru yaparsanız geri kalan her şey basittir. Yanlış yaparsanız, bir şeyler çökene kadar bağlantı sızıntısı yaşarsınız. Bu kılavuz, temel bilgileri, ara alıcıları, zaman aşımlarını ve proxy'leri ele alır; ayrıca, projenin şu anda bulunduğu yerle ilgili bir not da içerir (bu bilgi değişmiştir).

Konuyla ilgimiz: Biz Geonode olarak proxy satışı yapıyoruz ve OkHttp’in proxy yapılandırması gerçekten sıra dışıdır — proxy kimlik doğrulaması bir başlık (header) üzerinden değil, proxyAuthenticator adresi üzerinden gerçekleştirilir; bunu yanlış yapıldığında, aslında bir yapılandırma sorunu olmasına rağmen kimlik bilgileri sorunu gibi görünen bir 407 hatası ortaya çıkar. Bu bölüm yazının sonlarına doğru yer almaktadır. Ondan önceki her şey proxy olmadan da çalışır; kütüphaneyi öğreniyorsanız, önce kendi bağlantınız üzerinden deneyin.

OkHttp Artık Nerede Bulunuyor?

Eski bağlantılar artık çalışmadığından, bunu baştan belirtmekte fayda var.

OkHttp’nin depo adresi değiştirildi. github.com/square/okhttp

artık github.com/lysine-dev/okhttp

adresine yönlendiriyor ve square.github.io/okhttp

adresinde bulunan dokümantasyon sitesi 404 hatası veriyor — güncel site lysine.dev/okhttp

adresinde yer alıyor. Proje aktif olarak sürdürülmekte olup, Eylül 2026'da doğrulandığı üzere Apache-2.0 lisansı altındadır.

Maven koordinatlarında herhangi bir değişiklik olmamıştır. Hala com.squareup.okhttp3:okhttp

olarak yayınlanmaktadır:

implementation("com.squareup.okhttp3:okhttp:5.5.0")

Ayrıca, ilgili yapıları güncel tutmak için bir malzeme listesi de mevcuttur:

implementation(platform("com.squareup.okhttp3:okhttp-bom:5.5.0"))

Gereksinimler: Android 5.0+ (API seviyesi 21+) ve Java 8+. OkHttp, I/O işlemleri için Okio'ya ve Kotlin standart kütüphanesine bağımlıdır — her ikisi de proje tarafından "güçlü geriye dönük uyumluluğa sahip küçük kütüphaneler" olarak tanımlanmaktadır. Android'de AndroidX Startup kullanılır; manifest dosyasında başlatıcıyı devre dışı bırakırsanız, uygulamanızın Application.onCreate

adresindeki OkHttp.initialize(applicationContext)

yöntemini çağırması gerekir.

Eski 3.12.x

dalı, Android 2.3+ ve Java 7'yi destekler; proje, bu platformların "TLS 1.2 desteğinden yoksun olduğunu ve kullanılmaması gerektiğini" açıkça belirtir.

İlk İsteğiniz

OkHttpClient client = new OkHttpClient();

String run(String url) throws IOException {
  Request request = new Request.Builder()
      .url(url)
      .build();

  try (Response response = client.newCall(request).execute()) {
    return response.body().string();
  }
}

Bu yedi satırlık örnekte üç husus önemlidir.

**try

-with-resources seçeneği zorunludur.** Response

, Closeable

arayüzünü uygular ve kapatılmamış bir yanıt, bağlantısını açık tutar. Yeterince bağlantı kaçağı olursa havuz tükenir; bu noktada istekler hata vermek yerine askıda kalır — bu durum, ağ sorunu gibi görünse de aslında öyle değildir.

**body().string()

bir kez çağrılabilir.** Bu işlev akışı tüketir. İki kez çağrılması istisna oluşturur; yanıt kapatıldıktan sonra çağrılması da istisna oluşturur. İçeriğe birden fazla kez ihtiyacınız varsa, dizgiyi saklayın.

**execute()

işlevi senkron çalışır.** Asenkron işlemler için, enqueue()

işlevi bir Callback

alır ve OkHttp’nin dağıtıcı iş parçacığı havuzunda çalışır.

POST isteği, gövdeli olarak aynı yapıya sahiptir:

public static final MediaType JSON = MediaType.get("application/json");

String post(String url, String json) throws IOException {
  RequestBody body = RequestBody.create(json, JSON);
  Request request = new Request.Builder()
      .url(url)
      .post(body)
      .build();
  try (Response response = client.newCall(request).execute()) {
    return response.body().string();
  }
}

İstemciyi Paylaşın

Kullanıcıların en sık yanlış yaptığı tasarım kararı.

OkHttpClient

bir bağlantı havuzu ve bir iş parçacığı havuzu barındırır. Her istek için ayrı bir istemci oluşturmak, yeniden kullanabileceğiniz tüm bağlantıları boşa harcar ve daha sonra terk edeceğiniz iş parçacıkları oluşturur. Bu yöntem çalışır, ancak yavaştır ve yük altında kaynakları tüketir.

Uygulamanız için tek bir istemci oluşturun ve bunu paylaşın. Tasarım gereği iş parçacığı güvenlidir.

Kodunuzun bir bölümü için farklı ayarlara ihtiyacınız olduğunda, ikinci bir istemciyi sıfırdan oluşturmayın — mevcut olanı klonlayın, böylece havuzlar paylaşılır:

OkHttpClient shortTimeout = client.newBuilder()
    .readTimeout(5, TimeUnit.SECONDS)
    .build();

newBuilder()

, bağlantı havuzunu ve dağıtıcıyı üst öğesiyle paylaşan bir istemci oluşturur; bu tam da istediğiniz şeydir.

Kapatma işlemi için, özellikle kısa ömürlü işlemlerde, kaynakları açıkça serbest bırakın:

client.dispatcher().executorService().shutdown();
client.connectionPool().evictAll();

Bu yapılmazsa, JVM çıkmadan önce havuzun keep-alive süresi boyunca askıda kalabilir; bu da bir CLI aracında hata ayıklamayı zorlaştıran bir durumdur.

OkHttp’nin İsteğinize Eklediği Şeyler

Bu kütüphane istekleri yeniden yazmaktadır ve ne eklediğini bilmek, bazı karışıklıkları önler.

Belgelerde açıkça belirtilmiştir: "OkHttp, orijinal istekte bulunmayan başlıkları ekleyebilir; bunlara Content-Length, Transfer-Encoding, User-Agent, Host, Connection ve Content-Type dahildir. Başlık zaten mevcut değilse, şeffaf yanıt sıkıştırması için Accept-Encoding başlığını ekler. Çerezleriniz varsa, OkHttp bunlarla birlikte Cookie başlığını ekler."

Bunun iki sonucu vardır.

Şeffaf sıkıştırma otomatik olarak gerçekleşir ve sizin için tersine çevrilir. OkHttp sıkıştırma talebinde bulunur, yanıtı açar ve ardından "Content-Encoding ve Content-Length başlıklarını, açılmış yanıt gövdesine uygulanmadıkları için kaldırır". Dolayısıyla, bir yanıtta Content-Length başlığının eksik olması bir hata değil, normaldir — tabii ki Accept-Encoding başlığını kendiniz ayarlamadıysanız; bu durumda sıkıştırmanın açılması sizin sorumluluğunuzdadır.

Önbellekleme etkinleştirildiğinde koşullu istekler otomatik olarak gerçekleşir. OkHttp, eski önbellek girdilerini yeniden doğrulamak için If-Modified-Since ve If-None-Match adreslerini ekler.

Ayrıca varsayılan olarak yönlendirmeleri takip eder ve bir yetkilendirme talebi geldiğinde, "talebi karşılamak için Authenticator adresine (eğer yapılandırılmışsa) başvurur" ve sağlanan kimlik bilgileriyle yeniden deneme yapar.

Kütüphane kendini “ilkelere bağlı ve aşırı yapılandırılabilir olmaktan kaçınan” olarak tanımlar; özellikle de bu tür yapılandırmaların hatalı bir sunucuyu atlatmak, geçersiz senaryoları test etmek veya ilgili RFC ile çelişen durumlar için kullanılması söz konusu olduğunda. Kendi sınırlamalarını dürüstçe belirtir — "gövde içeren GET isteklerine izin vermez" ve önbellek "alternatif uygulamalara sahip bir arayüz değildir". Kasıtlı olarak geçersiz istekler göndermeniz gerekiyorsa, bu kütüphane bunun için uygun değildir; bu, bir gözden kaçma değil, tasarım tercihidir.

Interceptor'lar

Ana genişletme noktası ve kütüphaneyi kullanma şeklinizi belirleyecek tek özellik.

class LoggingInterceptor implements Interceptor {
  @Override public Response intercept(Interceptor.Chain chain) throws IOException {
    Request request = chain.request();
    long t1 = System.nanoTime();
    logger.info(String.format("Sending request %s on %s%n%s",
        request.url(), chain.connection(), request.headers()));

    Response response = chain.proceed(request);

    long t2 = System.nanoTime();
    logger.info(String.format("Received response for %s in %.1fms%n%s",
        response.request().url(), (t2 - t1) / 1e6d, response.headers()));
    return response;
  }
}

Belgelerde şu husus özellikle vurgulanmaktadır: “chain.proceed(request)’a yapılan çağrı, her bir interceptor’ın uygulamasının kritik bir parçasıdır. Bu basit görünen yöntem, tüm HTTP işlemlerinin gerçekleştiği yerdir.” Ve dikkate alınması gereken bir uyarı: "chain.proceed(request) bir defadan fazla çağrılıyorsa, önceki yanıt gövdeleri kapatılmalıdır."

İki tür vardır ve doğru seçim yapmak önemlidir. addInterceptor() veya addNetworkInterceptor() ile kayıt olun. Belgelerde aradaki fark kesin olarak açıklanmaktadır.

Uygulama ara alıcıları:

  • "Yönlendirmeler ve yeniden denemeler gibi ara yanıtlar konusunda endişelenmenize gerek yoktur."
  • "HTTP yanıtı önbellekten sunulsa bile her zaman bir kez çağrılır."
  • "Uygulamanın asıl amacını gözetir. If-None-Match gibi OkHttp tarafından eklenen başlıklarla ilgilenmez."
  • "Chain.proceed()'i çağırmadan işlemi kısa devre yapabilir."
  • "Chain.proceed()'e yeniden deneme yapabilir ve birden fazla çağrı gönderebilir."
  • "withConnectTimeout, withReadTimeout, withWriteTimeout kullanılarak çağrı zaman aşımları ayarlanabilir."

Ağ ara alıcıları:

  • "Yönlendirmeler ve yeniden denemeler gibi ara yanıtlar üzerinde işlem yapabilir."
  • "Ağı atlayan önbelleğe alınmış yanıtlar için çağrılmaz."
  • "Verileri, ağ üzerinden iletileceği haliyle gözlemler."
  • "İsteği taşıyan Connection dosyasına erişebilir."

Pratik kural: isteğinizin amacıyla ilgili her şey için bir uygulama ara alıcısı kullanın — yetkilendirme başlığı eklemek, kullanıcı ajanı eklemek, uygulama düzeyinde günlük kaydı tutmak gibi. Ağın üzerinden fiilen geçen her şey için bir ağ ara katmanı kullanın — sıkıştırılmış gövdeleri incelemek, her yönlendirme adımını görmek, bağlantıyı incelemek gibi.

En yaygın hata, bir yetkilendirme ara katmanını ağ ara katmanı olarak kaydetmektir; bu durumda ara katman her yönlendirme adımında bir kez tetiklenir ve kimlik bilgilerinizi istemediğiniz bir ana bilgisayara sızdırabilir.

Zaman Aşımları

OkHttp’nin mantıklı varsayılan ayarları ve dört ayrı ayarı vardır; hangisinin tetiklendiğini bilmek, sorunun nerede olduğunu anlamanıza yardımcı olur.

OkHttpClient client = new OkHttpClient.Builder()
    .connectTimeout(10, TimeUnit.SECONDS)
    .readTimeout(30, TimeUnit.SECONDS)
    .writeTimeout(30, TimeUnit.SECONDS)
    .callTimeout(60, TimeUnit.SECONDS)
    .build();

**connectTimeout

**, TCP ve TLS bağlantısının kurulmasını ele alır. **readTimeout

**, yanıtın tamamına değil, tek tek okuma işlemleri arasında geçerlidir — bu nedenle, yavaş ama ilerleyen bir indirme işlemi bu zaman aşımını asla tetiklemez. **writeTimeout

**, yüklemeler için de aynı işlevi görür. **callTimeout

**, yönlendirmeler, yeniden denemeler ve gövde aktarımı dahil olmak üzere tüm çağrıyı sınırlar. Varsayılan olarak sıfırdır, yani genel bir sınır yoktur.

Ayarlanması gereken son ayar budur. Bu ayar olmadan, veriyi yavaş yavaş aktaran bir çağrı süresiz olarak çalışabilir, çünkü okuma zaman aşımı alınan her baytta sıfırlanır. callTimeout

, bir işin tamamlanmasını sağlayan üst sınırdır ve curl'daki --max-time

ile aynı işlevi görür — bu ayrımı curl ile zaman aşımı ayarlama başlıklı yazımızda ele almıştık.

Çağrı başına geçersiz kılmalar, uygulama engelleyicisinin withReadTimeout

ve benzerleri aracılığıyla kullanılabilir; bu sayede, her şey için varsayılan ayarları gevşetmeden tek bir yavaş uç noktaya daha fazla alan tanıyabilirsiniz.

Proxy'ler

OkHttp'nin çoğu istemciden farklı olduğu ve kullanıcıların zaman kaybettiği nokta budur.

Proxy proxy = new Proxy(Proxy.Type.HTTP,
    new InetSocketAddress("proxy.example.com", 9000));

OkHttpClient client = new OkHttpClient.Builder()
    .proxy(proxy)
    .build();

SOCKS için, aynı yapıya sahip Proxy.Type.SOCKS adresini kullanın.

Kimlik doğrulama, kullanıcıları şaşırtan kısımdır. Proxy-Authorization başlığını ayarlamazsınız. proxyAuthenticator'i sağlarsınız; OkHttp, proxy 407 sorgusu gönderdiğinde bunu çağırır:

Authenticator proxyAuth = (route, response) -> {
  if (response.request().header("Proxy-Authorization") != null) {
    return null;   // already tried these credentials; give up
  }
  String credential = Credentials.basic("user", "pass");
  return response.request().newBuilder()
      .header("Proxy-Authorization", credential)
      .build();
};

OkHttpClient client = new OkHttpClient.Builder()
    .proxy(proxy)
    .proxyAuthenticator(proxyAuth)
    .build();

Null dönüş değeri çok önemlidir. Bu olmadan, yanlış bir şifre hata yerine sonsuz bir yeniden deneme döngüsüne neden olur — OkHttp kimlik doğrulayıcıya sorar, aynı hatalı kimlik bilgilerini alır, başka bir 407 alır ve tekrar sorar. Proxy-Authorization başlığını daha önce gönderip göndermediğinizi kontrol etmek, bu döngüyü kırmanın yoludur.

Üç ek not.

407, 401 değildir. Proxy sizi reddetti ve hedefe asla ulaşamadı. 401 ise, proxy'nin çalıştığı ve hedefin kimlik bilgilerini istediği anlamına gelir; bu, tamamen farklı bir authenticator() ayarıdır.

proxySelector(), istemci başına değil istek başına bir proxy seçmenize olanak tanır; bu sayede, birden fazla istemci oluşturmadan farklı ana bilgisayarları farklı şekilde yönlendirebilirsiniz.

Değişikliğin yürürlüğe girdiğini doğrulayın. Proxy yapılandırılmış ve yapılandırılmamış durumlarda, adresinizi yansıtan bir hizmet isteğinde bulunun. Buradaki bir yapılandırma hatası fark edilmez — istekler başarılı olur ve doğrudan iletilir — ve emin olmanın tek yolu çıkış adresini doğrulamaktır. Bu "fark edilmeyen başarı" örüntüsü, proxy'leri test etmenin neden önemli olduğu başlıklı yazımızda ele aldığımız konudur.

Yanıtları Doğru Şekilde İşleme

Çalışan kod ile yük altında çalışan kod arasındaki farkı yaratan birkaç örüntü.

**Sadece istisna olup olmadığını değil, isSuccessful()

adresini de kontrol edin.** OkHttp, HTTP hata durumları için değil, ağ hataları içIOException

'i atar. Bir 404 veya 500 hatası, sıradan bir Response

olarak gelir:

try (Response response = client.newCall(request).execute()) {
  if (!response.isSuccessful()) {
    String body = response.body() != null ? response.body().string() : "";
    throw new IOException("HTTP " + response.code() + " from " + request.url()
                          + ": " + body.substring(0, Math.min(200, body.length())));
  }
  return response.body().string();
}

Hata gövdesinin ilk kısmını eklemek, anlaşılmaz bir durum kodunu sorunun adını belirten bir mesaja dönüştürür — çoğu API, 400 kodunun gövdesinde kendini açıklar.

Büyük yanıtları bir String'e tamponlamayın. body().string()

her şeyi belleğe okur. Büyük bir indirme için akış kullanın:

try (Response response = client.newCall(request).execute();
     BufferedSource source = response.body().source();
     BufferedSink sink = Okio.buffer(Okio.sink(new File("out.bin")))) {
  sink.writeAll(source);
}

Asenkron çağrılarda da gövdenin kapatılması gerekir ve geri arama arka plan iş parçacığında çalışır:

client.newCall(request).enqueue(new Callback() {
  @Override public void onFailure(Call call, IOException e) {
    logger.warn("request failed", e);
  }
  @Override public void onResponse(Call call, Response response) throws IOException {
    try (ResponseBody body = response.body()) {
      handle(body.string());
    }
  }
});

onFailure

'in yalnızca ağ sorunlarında tetiklendiğine dikkat edin. HTTP 500 hatası onResponse

adresine ulaşır; bu durum, hatanın adının anlamının kelime anlamıyla aynı olduğunu düşünen kullanıcıları şaşırtır.

Yeniden denemeler dikkat gerektirir. OkHttp, varsayılan olarak etkin olan retryOnConnectionFailure()

ile kontrol edilen bazı bağlantı düzeyindeki hataları otomatik olarak yeniden dener. HTTP hata durumlarını yeniden denemez ve denememelidir — başarılı olmuş olabilecek bir POST isteğini yeniden denemek, bir yazma işleminin iki kez gerçekleşmesine neden olabilir. Kendi yeniden deneme mantığınızı ekleyeceğiniz yerlerde, bunu bir uygulama ara alıcısında yapın, deneme sayısını sınırlayın, denemeler arasında bekleme süresi bırakın ve API bir idempotans anahtarı sunmadıkça bunu idempotent yöntemlerle sınırlayın.

Size Sunduğu Diğer Avantajlar

Kısaca, işte onu tercih etmeniz için nedenler.

HTTP/2; bu protokolde “destek sayesinde aynı ana bilgisayara yapılan tüm istekler tek bir soketi paylaşabilir”. Bağlantı havuzu, "istek gecikmesini azaltır (HTTP/2 kullanılamıyorsa)". Şeffaf GZIP. Yanıt önbellekleme, "tekrarlanan istekler için ağ bağlantısını tamamen ortadan kaldırır".

Esneklik. "Yaygın bağlantı sorunlarından sessizce kurtulur" ve bir hizmetin birden fazla adresi olması durumunda "ilk bağlantı başarısız olursa alternatif adresleri dener" — projenin belirttiği gibi bu, "IPv4+IPv6 ve yedekli veri merkezlerinde barındırılan hizmetler için gereklidir".

Modern TLS, TLS 1.3, ALPN ve sertifika sabitleme dahil olmak üzere, platformun kendi uygulamasını kullanır. JVM üzerinde ayrıca, BoringSSL’i Java ile entegre eden Conscrypt’i destekler; bu, ilk güvenlik sağlayıcısı olması durumunda otomatik olarak kullanılır.

Standartlara uygunluk. Proje, uyduğu spesifikasyonları şöyle listelemektedir: HTTP semantiği için RFC 9110, önbellekleme için RFC 9111, HTTP/1.1 için RFC 9112, HTTP/2 için RFC 9113, WebSockets için RFC 6455 ve sunucu tarafından gönderilen olaylar için WHATWG spesifikasyonu. Bir spesifikasyonun belirsiz olduğu durumlarda, proje “popüler tarayıcılar veya yaygın HTTP kütüphaneleri gibi modern kullanıcı aracılarını takip eder”.

Sıkça Sorulan Sorular

OkHttp hâlâ güncelleniyor mu?

Evet. Depo, square/okhttp adresinden lysine-dev/okhttp adresine taşınmış ve dokümantasyon sitesi artık lysine.dev/okhttp adresinde yer almaktadır; ancak proje aktif olarak geliştirilmekte ve Apache-2.0 lisansı altında bulunmaktadır. Maven koordinatları com.squareup.okhttp3:okhttp olarak kalmıştır.

Her istek için yeni bir OkHttpClient oluşturmalı mıyım?

Hayır. İstemci, bir bağlantı havuzu ve bir iş parçacığı havuzu barındırır ve tasarım gereği iş parçacığı güvenlidir. Uygulamanız için bir tane oluşturun ve bunu paylaşın. Farklı ayarlara ihtiyacınız olduğunda, havuzların paylaşılabilmesi için mevcut istemci üzerinde newBuilder() komutunu kullanın.

Neden yanıtı kapatmam gerekiyor?

Çünkü Response, kapatılana kadar bağlantıyı tutar ve sızan yanıtlar bağlantı havuzunu tüketir. Bunun belirtisi, isteklerin başarısız olmaktansa askıda kalmasıdır; bu da teşhis edilmesi zor bir durumdur. Her zaman try-with-resources kullanın.

Uygulama ve ağ ara alıcısı arasındaki fark nedir?

Bir uygulama ara alıcısı, orijinal isteğinizi görür ve önbelleğe alınmış yanıtlar için bile tam olarak bir kez çağrılır; ayrıca işlemi kısa devre yapabilir veya yeniden deneme yapabilir. Bir ağ ara alıcısı ise yönlendirmeler ve yeniden denemeler dahil olmak üzere her bir ağ alışverişini görür, bağlantıya erişebilir ve önbelleğe alınmış yanıtlar için tamamen atlanır.

OkHttp'de proxy'yi nasıl ayarlarım?

OkHttpClient.Builder.proxy()'a bir java.net.Proxy aktarın. Kimlik doğrulama için, başlık yerine bir proxyAuthenticator ayarlayın — ve Proxy-Authorization başlığı zaten mevcutsa veya yanlış kimlik bilgileri sonsuz bir yeniden deneme döngüsüne neden oluyorsa, null değerini döndürün.

Hangi zaman aşımlarını ayarlamalıyım?

connectTimeout'i yaklaşık 10 saniyeye, readTimeout ve writeTimeout'i yaklaşık 30 saniyeye ayarlayın ve — en önemlisi — varsayılan değeri sıfır olan ve tüm çağrıyı sınırlayan tek ayar olan callTimeout'i ayarlayın. Bu ayar olmadan, yavaşça gelen bir yanıt asla zaman aşımına uğramaz çünkü okuma zaman aşımı her baytta sıfırlanır.

OkHttp, GZIP'i otomatik olarak işliyor mu?

Evet, Accept-Encoding değerini kendiniz ayarlamazsanız. Sıkıştırma talebinde bulunur, yanıtı açar ve Content-Encoding ile Content-Length başlıklarını, artık açılmış gövdeyi tanımlamadıkları için kaldırır. Başlığı manuel olarak ayarlarsanız, sıkıştırmayı açma işlemi de size kalır.

OkHttp hangi Java sürümünü gerektirir?

Java 8 veya üstü ve Android 5.0 (API seviyesi 21) veya üstü. Bu, Okio ve Kotlin standart kütüphanesine bağlıdır. Eski 3.12.x dalı, Java 7 ve Android 2.3'ü destekler ancak TLS 1.2 desteği yoktur ve kullanılmamalıdır.

Sonuç

OkHttp, özenle tasarlanmış bir uygulamaya dayanan küçük bir API’dir ve doğru kullanımının büyük kısmı iki alışkanlıkla sağlanır: Uygulamanız genelinde tek bir istemciyi paylaşın ve her yanıtı ``try-with-resources ile kapatın. Her iki hata da sessizce gerçekleşir ve her ikisi de sonunda, okuyabileceğiniz hatalar yerine takılan istekler şeklinde ortaya çıkar.

Zamanınızı en çok interceptor’lara ayıracaksınız; uygulama ile ağ arasındaki farkı deneme yanılma yoluyla değil, doğru bir şekilde öğrenmeye değer. Uygulama interceptor’ları amacınızı algılar ve bir kez çalışır; ağ interceptor’ları ise her adımı izler ve önbelleğe alınmış yanıtlarda atlanır. Ağ katmanında bir yetkilendirme interceptor'ı kaydetmek klasik bir hatadır ve bu, her yönlendirmede tetiklenir.

callTimeout değerini ayarlayın. Varsayılan değeri sıfırdır; bu, tüm çağrıyı sınırlayan tek ayardır ve bu ayarın olmaması, saniyeler sürmesi gereken bir işin zaman zaman başka bir şey tarafından sonlandırılana kadar çalışmaya devam etmesinin sebebidir.

Eski belgeleri takip ediyorsanız, bağlantıları kontrol edin. Proje lysine.dev/okhttp adresine taşınmıştır ve Square tarafından barındırılan site artık mevcut değildir — ancak artefakt koordinatları değişmemiştir, bu nedenle derleme dosyanızda herhangi bir değişiklik yapmanız gerekmez.