Retrofit: vad är det, egenskaper hos Android HTTP-klienten

Vad är Retrofit?

Retrofit — är ett bibliotek för typad interaktion med REST API på Android-plattformen, utvecklat av företaget Square. Det ger ett deklarativt sätt att beskriva HTTP-förfrågningar via Java- eller Kotlin-gränssnitt med annoteringar, vilket helt befriar utvecklaren från manuell JSON-tolkning och hantering av HTTP-anslutningar.

Biblioteket dök upp 2013 som ett alternativ till tunga lösningar som AsyncTask och HttpURLConnection. Fram till 2025 förblir Retrofit de facto-standarden för nätverkskommunikation i Android-applikationer tack vare enkelhet och typsäkerhet. Enligt JetBrains Developer Ecosystem 2024-undersökningen använder över 65% av Android-utvecklare Retrofit i kommersiella projekt.

Den viktigaste skillnaden mellan Retrofit och alternativ — det deklarativa tillvägagångssättet: utvecklaren beskriver vad som ska göras (vilken endpoint som ska anropas, vilka parametrar som ska skickas), inte hur det ska göras (hur man öppnar anslutningen, hur man läser InputStream, hur man tolkar JSON). Detta minskar mängden boilerplate-kod med 60–70% jämfört med manuell användning av HttpURLConnection.

Hur Retrofit fungerar

Funktionsprincipen för Retrofit är baserad på Java-dynamiska proxys. När en utvecklare anropar en metod i ett gränssnitt som är markerat med annoteringar, fångar Retrofit via Proxy.newProxyInstance-mekanismen upp anropet och omvandlar det till en HTTP-förfrågan. Hela processen sker under körning utan kodgenerering i kompileringsfasen.

När en Retrofit.Builder-instans skapas anges bas-URL och konverterarfabrik. Builder konfigurerar OkHttpClient — ställer in timeouter, interceptorer, anslutningspool och cache. Metoden create(Class) genererar implementeringen av gränssnittet och returnerar ett proxyobjekt som kan anropas som en vanlig klass.

Kedjan för att utföra en förfrågan ser ut så här: annoteringar extraherar HTTP-metoden, parametrar sätts in i URL:en eller förfrågans brödtext, konverteraren serialiserar brödtexten, OkHttp utför förfrågan, konverteraren deserialiserar svaret, resultatet returneras i den angivna typen. Varje steg är isolerat och kan ersättas med en anpassad implementering, till exempel att ersätta OkHttpClient med MockWebServer för testning eller byta konverterare vid API-ändring.

Viktig egenskap — Retrofit stöder inte direkt dataströmning. För strömning används OkHttp ResponseBody som returtyp för gränssnittets metod. Retrofit hanterar inte heller automatiskt avbokning av förfrågningar — för att avbryta måste en referens till Call sparas och cancel() anropas. I Kotlin med suspend-funktioner sker avbokning av förfrågan automatiskt när den överordnade koroutinen avbryts.

Livscykel för Call-objektet

Call<T> — är ett objekt som representerar en enda HTTP-förfrågan. Efter utförande (execute eller enqueue) kan Call inte återanvändas — för en upprepad förfrågan måste en ny Call skapas genom att anropa gränssnittsmetoden. Detta skyddar mot att samma förfrågan skickas två gånger av misstag, vilket skulle kunna leda till dubbiering av operationer på servern.

I Kotlin används istället för Call suspend-funktioner som automatiskt hanterar förfrågans livscykel. Retrofit växlar själv utförandet till Dispatchers.IO och returnerar resultatet till koroutinen. Detta förkortar koden med 30–40% jämfört med versionen med Call och Callback.

Retrofit-annoteringar för HTTP-metoder

Annoteringar — är den huvudsakliga mekanismen för att konfigurera HTTP-förfrågningar i Retrofit. Varje annotering motsvarar en standard HTTP-metod och accepterar en relativ sökväg till endpoint. Retrofit stöder GET, POST, PUT, DELETE, PATCH, HEAD och OPTIONS.

Annoteringar för förfrågningsparametrar

@Path ersätter värdet i URL-segmentet: @Path(id) Int id ersätter {id} i sökvägen. @Query lägger till en query-parameter: @Query(page) Int page blir ?page=5. @Body skickar ett objekt i förfrågans brödtext med automatisk serialisering via den valda konverteraren. @Header och @Headers hanterar HTTP-rubriker — statiska eller dynamiska.

Genom att kombinera dessa annoteringar kan vilken REST-endpoint som helst beskrivas. Till exempel, för endpoint POST /api/users/{id}/posts?limit=10 behövs @POST, @Path för id, @Query för limit och @Body för det skickade objektet. Retrofit sammanställer automatiskt den korrekta HTTP-förfrågan. Dessutom stöds @Url (dynamisk URL), @Field (form-encoded brödtext), @Part och @PartMap för multipart-förfrågningar med filer.

Retrofit-kodexempel i Kotlin

Låt oss titta på ett praktiskt exempel — ett gränssnitt för GitHub API. Ett Kotlin-gränssnitt skapas med en metod för att hämta en lista med repositories. Data class Repo beskriver strukturen för JSON-svaret.

data class Repo(
    val name: String,
    val description: String?,
    val stargazersCount: Int,
    val forksCount: Int
)

interface GitHubApi {
    @GET("users/{user}/repos")
    suspend fun getRepos(
        @Path("user") user: String,
        @Query("sort") sort: String = "updated"
    ): List<Repo>
}

Efter att ha beskrivit gränssnittet skapas en Retrofit-instans via Builder. Bas-URL, konverterare och OkHttpClient konfigureras en gång och återanvänds via dependency injection.

val retrofit = Retrofit.Builder()
    .baseUrl("https://api.github.com/")
    .addConverterFactory(GsonConverterFactory.create())
    .client(OkHttpClient.Builder()
        .connectTimeout(30, TimeUnit.SECONDS)
        .build())
    .build()

val api = retrofit.create(GitHubApi::class.java)

Bearbetning av svar med Response-omslag

För flexibel bearbetning av HTTP-statusar använd Response<T>-omslaget. Det ger tillgång till svarskod, rubriker och brödtext utan att kasta undantag vid 4xx- och 5xx-fel. Detta gör det möjligt att hantera 404 och 500 utan try-catch.

interface GitHubApi {
    @GET("users/{user}/repos")
    suspend fun getRepos(
        @Path("user") user: String
    ): Response<List<Repo>>
}

val response = api.getRepos("octocat")
if (response.isSuccessful) {
    println(response.body()?.size)
} else {
    Log.e("API", "Fel: ${response.code()}")
}

Konverterare och serialisering i Retrofit

Konverterare — är Retrofit-komponenter som ansvarar för att omvandla objekt till HTTP-brödtext och vice versa. Retrofit bygger inte in serialisering i kärnan — istället används ett modulärt tillvägagångssätt via Converter.Factory, vilket gör det möjligt att ansluta valfritt serialiseringsbibliotek.

Den populäraste konverteraren — GsonConverterFactory från Google baserad på Gson-biblioteket. Den passar för de flesta projekt, stöder anpassade TypeAdapter och JsonDeserializer. Gson använder dock reflektion och tar inte hänsyn till Kotlin null safety, vilket kan leda till NPE vid oväntade null-fält.

Alternativ — MoshiConverterFactory från Square: strängare med typer, med bättre stöd för Kotlin (null safety, default values) och utan reflektion. För projekt i ren Kotlin är Kotlinx Serialization Converter optimalt, som arbetar med @Serializable-annoteringar i kompileringsfasen. Den använder inte reflektion, stöder sealed class, default values och multiplattform.

Valet av konverterare påverkar prestanda och säkerhet för typer. Gson utan anpassad konfiguration kan deserialisera null till ett non-null-fält i Kotlin, vilket orsakar NPE vid åtkomst. Moshi löser detta problem genom @Json(name)-annoteringen och failOnUnknown. Kotlinx Serialization är säkrast — den genererar kod i kompileringsfasen, vilket helt eliminerar runtime-typfel.

Vanliga misstag vid arbete med Retrofit

Avsaknad av HTTP-felhantering i suspend-funktioner — det vanligaste problemet. Om servern returnerar 4xx eller 5xx kastar Retrofit HttpException. Utan try-catch kraschar applikationen. Att använda Response<T> som returtyp löser detta problem genom att möjliggöra kontroll av isSuccessful innan body nås.

Felaktig cache-konfiguration leder till överdriven trafik. Retrofit cachar inte svar själv — denna uppgift löses av OkHttpClient via Cache. Utan cache utförs varje förfrågan fullständigt, även när data inte har ändrats. Att lägga till en Cache på 10 MB i OkHttpClient minskar trafiken med 40–60% vid upprepade förfrågningar av samma information.

Skapa Retrofit för varje förfrågan — ett vanligt misstag för nybörjare. Retrofit.Builder är en resurskrävande operation som innefattar generering av proxy-klasser under körning. Korrekt praxis — skapa en Retrofit-instans och återanvända den via DI-ramverk. Hilt, Koin eller Dagger tillhandahåller en singleton Retrofit-instans för hela applikationen, vilket sparar minne och snabbar upp förfrågningar.

Ignorera Interceptor för auktorisering — det fjärde problemet. Istället för att manuellt lägga till Authorization-rubriken i varje anrop, konfigurera en global Interceptor i OkHttpClient. Interceptorn fångar upp varje förfrågan, lägger till Bearer-token, och Authenticator bearbetar 401-svaret, förnyar token och upprepar förfrågan automatiskt. Detta centraliserar autentiseringslogiken.