REST API: vad är det, HTTP-metoder och arbetsprincip i mobilappar

Vad är REST API?

REST API (Representational State Transfer API) — är en arkitektonisk stil som föreslogs av Roy Fielding i hans doktorsavhandling år 2000. Den definierar en uppsättning begränsningar och principer för att designa nätverksprotokoll. Ett API som uppfyller dessa begränsningar kallas RESTful. REST är varken ett protokoll eller en standard — det är ett arkitektoniskt tillvägagångssätt som använder befintliga protokoll (främst HTTP) för datautbyte mellan klient och server.

Kärntanken med REST är resursorienterad arkitektur. Istället för att anropa metoder på servern (som i SOAP eller RPC) arbetar klienten med resurser: hämtar deras lista, skapar nya, uppdaterar eller tar bort. Varje resurs är en entitet inom domänen: användare, beställning, produkt, artikel. En resurs har ett tillstånd som överförs till klienten i ett standardiserat format, vanligtvis JSON. Servern lagrar inte klientens tillstånd mellan förfrågningar — detta är stateless-principen, ett centralt krav för REST.

Huvudegenskaper för REST API:

• Stateless — varje förfrågan från klienten innehåller all information som behövs för dess bearbetning
• Cacheable — serverns svar måste uttryckligen markeras som cachelagringsbara eller icke-cachelagringsbara
• Layered system — arkitekturen kan inkludera mellanliggande servrar, lastbalanserare, proxyservrar
• Uniform interface — enhetligt interaktionsgränssnitt via HTTP-metoder, URL:er och statuskoder

Principer för REST-arkitektur

REST är baserat på sex arkitektoniska begränsningar som formulerats av Fielding. Att följa dessa begränsningar garanterar skalbarhet, prestanda och enkel integration. Varje princip löser ett specifikt problem med distribuerade system — från behovet av caching till säkerhetskrav. Låt oss undersöka varje princip i detalj.

Principen Uniform Interface inkluderar ytterligare fyra underbegränsningar: identifiering av resurser via URI, manipulering av resurser via representationer, självbeskrivande meddelanden och HATEOAS (hypermedia som motor för applikationstillstånd). Den sista underbegränsningen ignoreras ofta i praktiken — de flesta moderna REST API:er implementerar inte HATEOAS fullt ut, vilket leder till diskussioner om huruvida ett sådant API är ”äkta” RESTful.

Principen Stateless — en av de viktigaste för skalning. Avsaknaden av sessioner på servern innebär att vilken serverinstans som helst kan bearbeta vilken förfrågan som helst. Detta förenklar horisontell skalning: det räcker att lägga till nya servrar bakom lastbalanseraren. För mobilappar innebär stateless också att en förfrågan kan skickas till vilken CDN-server som helst, vilket är avgörande för global tillgänglighet.

HTTP-metoder i REST

Varje HTTP-metod i REST API motsvarar en specifik operation på en resurs: GET för läsning, POST för att skapa, PUT för fullständig uppdatering, PATCH för partiell uppdatering, DELETE för borttagning. Idempotens hos metoder är en nyckelegenskap: GET, PUT, DELETE är idempotenta (upprepad exekvering ger samma resultat), POST och PATCH är det inte. Detta är viktigt för hantering av nätverksfel när klienten inte vet om förfrågan nådde servern.

• GET — hämtning av en resurs eller lista av resurser. Idempotent, ändrar inte serverns tillstånd
• POST — skapande av en ny resurs. Inte idempotent, varje anrop skapar en ny resurs
• PUT — fullständig ersättning av resurs. Idempotent, upprepat anrop ändrar inte tillstånd efter första
• PATCH — partiell uppdatering av resurs. Delvis idempotent (beroende på implementering)
• DELETE — borttagning av resurs. Idempotent, upprepad borttagning returnerar 404, inte ett fel

HTTP-statuskoder är en integrerad del av REST API. Varje kod har en specifik betydelse: 200 OK för lyckad GET, 201 Created för POST, 204 No Content för DELETE utan svarskropp, 400 Bad Request för ogiltig data, 401 Unauthorized vid avsaknad av autentisering, 404 Not Found vid avsaknad av resurs. Korrekt användning av statuskoder gör API:et självdokumenterande och förenklar felsökning.

Dataformat: JSON och andra

JSON (JavaScript Object Notation) — det huvudsakliga formatet för dataöverföring i REST API. Dess popularitet förklaras av enkelhet, läsbarhet för människor och inbyggt stöd i JavaScript. JSON överförs med huvudet Content-Type: application/json. Alternativ inkluderar XML (omfattande, föråldrat), YAML (bekvämt för konfiguration, mer sällan för API) och Protocol Buffers (binärt, effektivt för system med hög belastning).

Strukturen för ett JSON-objekt i REST API innehåller vanligtvis fälten id, type och resursattribut. För samlingar används en JSON-array med pagineringsmetadata. Moderna REST API:er följer specifikationen JSON:API (jsonapi.org) eller JSON Schema för validering av svar. Användning av ett enhetligt dataformat förenklar utvecklingen av klientbibliotek och generering av dokumentation.

Exempel på JSON-svar för en användarlista:

{
    "data": [
        {
            "id": 1,
            "name": "Anna Petrova",
            "email": "anna@example.com"
        }
    ],
    "meta": {
        "total": 42,
        "page": 1,
        "per_page": 10
    }
}

Valet av dataöverföringsformat påverkar prestandan för mobilappen. JSON komprimeras via GZIP med 70–80%, vilket gör det acceptabelt för de flesta scenarier. För realtidsapplikationer med stor datavolym (streaming, spel) rekommenderas att byta till binära protokoll eller använda WebSocket i kombination med Protocol Buffers.

Exempel på REST API-förfrågningar

Låt oss titta på praktiska exempel på arbete med REST API från mobilappens sida. Som exempel tar vi ett API för att hantera beställningar i en onlinebutik. För varje HTTP-metod visas förfrågan och det förväntade serversvaret. Exemplen visar den typiska strukturen för RESTful API som används inom mobil utveckling.

GET — hämta beställningslista

Förfrågan om att hämta alla beställningar för en användare med paginering. Svaret innehåller en array av beställningsobjekt och metainformation för sidnavigering. Parametrarna page och per_page skickas via query string.

// Retrofit-gränssnitt för REST API
interface OrderApi {
    @GET("api/v1/orders")
    suspend fun getOrders(
        @Query("page") page: Int = 1,
        @Query("per_page") perPage: Int = 20
    ): Response<OrderListResponse>
}

POST — skapa ny beställning

Skapa en ny beställning via en POST-förfrågan. Servern returnerar status 201 Created och det skapade objektet i svarskroppen. Viktigt: skapandet sker på samlingen /api/v1/orders, inte på en specifik resurs — detta är ett standardmönster för RESTful.

@POST("api/v1/orders")
suspend fun createOrder(
    @Body order: CreateOrderRequest
): Response<OrderResponse>

// Exempel på förfråganskropp
data class CreateOrderRequest(
    val productId: String,
    val quantity: Int,
    val addressId: String
)

DELETE — ta bort beställning

Borttagning av en resurs görs med DELETE-metoden på beställningens specifika URL. Lyckad borttagning returnerar 204 No Content. Idempotensen hos DELETE innebär att en upprepad förfrågan till samma URL returnerar 404 Not Found, vilket hanteras korrekt på klientsidan.

@DELETE("api/v1/orders/{id}")
suspend fun deleteOrder(
    @Path("id") orderId: String
): Response<Unit>

// Användning i ViewModel
fun removeOrder(orderId: String) {
    viewModelScope.launch {
        val response = api.deleteOrder(orderId)
        if (response.isSuccessful) {
            showSuccess()
        }
    }
}

Dessa exempel visar den typiska implementeringen av REST API på Android-sidan med Retrofit och Kotlin Coroutines. För iOS-appar fyller URLSession eller Alamofire-biblioteket i kombination med Codable-protokoll en liknande roll. REST API-strukturen förblir densamma oavsett plattform — endast sättet att utföra förfrågningar ändras.

RESTful API-design: praktiska rekommendationer

Att designa ett kvalitativt RESTful API kräver att man följer konventioner som gör API:et intuitivt för utvecklare. Resurser bör namnges med substantiv i plural (/users, /orders, /products), HTTP-metoder bör spegla operationer och URL:er bör visa hierarkisk struktur. Fel bör returnera en standardiserad JSON med kod och meddelande, inte bara HTTP-status. Att följa dessa konventioner sänker inträdesbarriären för nya utvecklare och förenklar integration.

• Namngivning av resurser — plural, kebab-case: /api/v1/user-orders, inte /api/v1/getUserOrders
• Filtrering och sortering — via query-parametrar: ?status=active&sort=created_at:desc
• Paginering — cursor-based för stora mängder, page-based för små
• Versionshantering — via URL (/api/v2/) eller huvudet Accept-Version
• Fel — enhetligt format: { "error": { "code": "VALIDATION_ERROR", "message": "..." } }
• Rate limiting — huvuden X-RateLimit-Remaining och Retry-After

Ett vanligt misstag vid design av REST API är överdriven häckning av resurser. Istället för /users/1/orders/5/items/3 är det bättre att använda en platt struktur med query-parametrar: /items?order_id=5&user_id=1. Detta förenklar caching, kräver inte stöd för långa sökvägar på servern och är lättare att dokumentera. Platt arkitektur är också mer kompatibel med graph-baserade frågor vid en övergång till GraphQL i framtiden.

Säkerhet för REST API realiseras genom autentisering (JWT, OAuth 2.0) och auktorisering på resursnivå. Varje förfrågan bör kontrollera om användaren har åtkomst till den begärda resursen. HTTPS är obligatoriskt — utan kryptering skickas tokens och data i klartext. För mobilappar rekommenderas att använda OAuth 2.0 med PKCE (Proof Key for Code Exchange) för säker inhämtning av tokens.

Versionshantering och caching

Versionshantering av REST API är nödvändig för bakåtkompatibilitet vid förändringar. De vanligaste tillvägagångssätten: version i URL (/api/v1/orders), version i huvud (Accept: application/vnd.myapi.v1+json) och version i query-parameter (?api_version=1). URL-versionshantering är den mest populära metoden eftersom den är tydligt synlig i loggar och dokumentation. Den bryter dock mot REST-principen om en unik resurs-URL.

Caching i REST API realiseras genom HTTP-huvuden Cache-Control, ETag och Last-Modified. GET-förfrågningar markerade som cachelagringsbara kan betjänas från webbläsarens eller proxyns cache utan att kontakta servern. För mobilappar är caching särskilt viktigt — det minskar dataförbrukning och snabbar upp visning av tidigare inläst data vid dålig anslutning. ETag är en hash av svarets innehåll: klienten skickar den i If-None-Match och servern returnerar 304 Not Modified om data inte har ändrats.

Moderna alternativ till REST API inkluderar GraphQL (flexibel dataselektering av klienten) och gRPC (binärt protokoll på HTTP/2 för mikrotjänster). REST förblir dock huvudstandarden för offentliga API:er tack vare sin enkelhet, universalitet och breda verktygsstöd. Valet mellan REST och alternativ beror på projektets specifika krav: förfrågningars komplexitet, datavolym, krav på realtidsuppdateringar.