Retrofit Rehberi
Bu yazı Retrofit Rehberinin 3.yazısıdır. Bir önceki yazıları okumadıysanız.
Retrofit URL Ayrıştırma
Metotları anlatmadan önce endpoint kullanımını biraz daha inceleyelim.
- Gitmek istediğimiz uzantı BaseURL + Endpoint şeklinde belirtilir
- BASE_URL mutlaka -/ile bitmelidir.
- Endpointler -/ ile başlamamalıdır.
METOTLAR
Şimdi geldik metotlarımıza. :) Sağ baştan sayarsak içlerinden biri tanıdık gelecektir.
- GET
- POST
- PUT
- DELETE
- OPTIONS
- HEAD
- PATCH
Bütün metotlar ile örnek yapmaya çalışacak olsam da şuan için metotların arasındaki farkları basitçe açıklayalım.
GET
Get metodu sunucuya herhangi bir veri için istek atıp yanıt alınan bir metottur. Bu metot bunu yaparken bilgileri url içerisinde gönderir. Hızlı bir yöntemdir. Burada bahsettiğimiz bilgileri sunucudan isterken endpointler ile istiyoruz.
POST
Post ile Get benzer yapılardır. Ancak burada temel fark post’ta sunucuya giden verinin body içine gizlenmesidir. Ayrıca Post isteği sunucuda bir objeyi yaratır.
PUT
PUT aslında POST ile çok benzerdir ancak verileri güncellemek için kullanabiliriz. PUT bir nesnenin tamamını günceller. Peki bir objenin bir alt objesini değiştirmek istersek? O zaman put bunu önemsemez gelen veri ile elindeki verinin ne olduğuna bakmadan sunucudaki objeyi tümüyle son haline günceller. Büyük nesneler için kullanışsızdır.
DELETE
Put’un tam tersidir. Sunucudan ilgili objeyi siler.
OPTIONS
Bu metot basit olarak sunucudan aktif olan metotları bize geri verir. O an için sunucunun hangi metotlara yanıt verebileceğini gösterir.
HEAD
Head metodu daha sonra detaylı olarak göreceğimiz Headerler konusunda bize yardımcı olur. Peki Header nedir? Header bir isteğin üstbilgileridir. Bazı durumlarda bu bilgilere ihtiyacımız olabilir. HEAD metodu GET metodu ile bu bağlamda benzer iş yapar. Ancak HEAD metoduna bir body dönmez. Bu metot sayesinde istek atılmadan kaynağın boyutunu geçerliliğini, erişilebilirliğini gibi yapıları öğrenebiliriz.
PATCH
Daha önce veri güncelleme işlemleri için PUT metodundan ve bunun büyük nesneler için kullanışsınız olduğundan bahsetmiştik. PATCH metodu bir objenin herhangi özelliğini değiştirebilir. Nesnenin tümünü göndermek zorunda kalmayız.
QUERIES
Daha önce endpointler ile alakalı örnek yapmıştık. Artık yollayacağımız isteği daha da spesifik hale getirecek query’lerden bahsedebiliriz. Örneğin bir sayfada özel olarak belli bir kullanıcının datasını çekmek istiyorsak o sayfanın endpoint’lerine ek olarak Query’ler ekleyebiliriz.
Örneğin;
https://reqres.in/api/users?page=2 adresinde
- Baseurl’imiz https://reqres.in/api/
- Endpoint’imiz users
- Querylerimiz ise page’dir. Spesifik bir sayfa söyleyip sadece oradaki verileri istiyoruz.
Diğer bir örnek;
api.openweathermap.org/data/2.5/weather?lat=35&lon=139&appid={API key} url’sinde
- BaseURL api.openweathermap.org/data/2.5/weather
- enlem,boylam ve ilgili api key birer query
ÖRNEK
Yeterince açıkladıysak devam edelim. Basit olması için ilk örneğimizin örneklerini yapalım.
Static
Interface’imizde bütün parametleri “@GET” fonksiyonu ile ilettik ancak burada kodu yazarken tüm parametleri elle girmiş olduk dolayısıyla bu bir sabit bir metottur. Bir yöntemdir, ne kadar doğrudur tartışılır.
Dynamic
Gene interface içerisinde yarattığımız yeni fonksiyonda endpoint’i “@GET” içine verdik daha sonra fonksiyonu çağırdığımızda ilgili parametreyi göndereceğimiz belirttik. Birden çok parametre istiyorsanız ilgili fonksiyon içine “@Query” annotation’ı ile diğer parametlere belirtebilirsiniz. (query parametresi ile parametre ismini aynı olmak zorunda metottan aldığımız parametre farklı olabilir.)
Yukarıda da api.callQueryDynamic diyerek ilgili parametreyi gönderip response’a ulaşmış olduk :)
UrlByPass
Ya da direkt ApiService tarafındaki es geçip bütün url’yi direkt interface içine koyup çağırabiliriz.
Dynamic Url
Dynamic URL metodunda bütün url’yi bir fonksiyonu vm’den değil şuan için apiservice’ten çağırıyoruz. Ve bu çağrıda gelen string’in url’imiz olacağını söyledik.
Url Path -Replacement Blocks
Şimdi atacağımız isteğin hem endpoint’ini belirlemek hem de query’imizi sunucuya göndermek istiyoruz. Peki bu durumda ne yapacağız? Hemen örnek üzerinden açıklayalım.
Bu sefer “@GET” annotation’ı içerisine süslü parantezler içine bir string yazdık. Daha sonra ilgili fonksiyonda yukarıda belirtilen süslü parantez içindeki entpoint aslında benim fonksiyondan alacağım uzantıdır dedik. Replacement block yani süslü parantez içindeki değişken ile “@Path” annotation’ı içindeki değişkenlerinin ismi aynı olması gerekmektedir.! Daha sonra da query’imizi basitçe ekledik.
Şimdi fonksiyonu çağıralım.
Ve işlem tamam ilgili call’lar yapıldıktan sonra cevap bize gelecektir! :)
Aslında yaptığımız işleme pagination da denir. Ancak biz burada bir taşla iki kuş vurmuş olduk :)
Proje dosyamız: https://github.com/inancyillmaz/Retrofit
4. Yazıda görüşmek üzere :)
