REST API: шта је то, HTTP методе и принцип рада у мобилним апликацијама

Шта је REST API?

REST API (Representational State Transfer API) — је архитектурни стил који је предложио Рој Филдинг у својој докторској дисертацији 2000. године. Он дефинише скуп ограничења и принципа за пројектовање мрежних протокола. API који испуњава ова ограничења назива се RESTful. REST није протокол нити стандард — то је архитектурни приступ који користи постојеће протоколе (претежно HTTP) за размену података између клијента и сервера.

Кључна идеја REST-а је ресурсно-оријентисана архитектура. Уместо позивања метода на серверу (као у SOAP или RPC), клијент оперише са ресурсима: добија њихову листу, креира нове, ажурира или брише. Сваки ресурс је ентитет домена: корисник, порућбина, производ, чланак. Ресурс има стање које се преноси клијенту у стандардизованом формату, обично JSON. Сервер не чува стање клијента између захтева — то је принцип stateless, кључни захтев REST-а.

Основне карактеристике REST API:

• Stateless — сваки захтев од клијента садржи све информације потребне за његову обраду
• Cacheable — одговори сервера морају бити јасно означени као кешираљиви или некешираљиви
• Layered system — архитектура може укључивати посредне сервере, балансере оптерећења, проксије
• Uniform interface — јединствени интерфејс за интеракцију путем HTTP метода, URL и статусних кодова

Принципи REST архитектуре

REST се заснива на шест архитектурних ограничења које је формулисао Филдинг. Поштовање ових ограничења гарантује скалабилност, перформансе и једноставност интеграције. Сваки принцип рјешава одређени проблем расподељених система — од потребе за кеширањем до захтева сигурности. Размотримо сваки принцип детаљно.

Принцип Uniform Interface додатно укључује четири подограничења: идентификацију ресурса путем URI, манипулисање ресурсима путем представа, самоописујуће поруке и HATEOAS (хипермедија као погонски мотор стања апликације). Посљедње подограничење се често занемарује у пракси — већина модерних REST API-ја не имплементира HATEOAS у потпуности, што доводи до расправа о томе да ли је таква API „прави“ RESTful.

Принцип Stateless — један од најважнијих за скалирање. Непостојање сесија на серверу значи да свака инстанца сервера може да обради било који захтев. То поједностављује хоризонтално скалирање: довољно је додати нове сервере иза балансера оптерећења. За мобилне апликације, stateless такође значи да захтев може бити послат било којем CDN серверу, што је критично за глобалну доступност.

HTTP методе у REST-у

Свака HTTP метода у REST API одговара одређеној операцији над ресурсом: GET за читање, POST за креирање, PUT за потпуно ажурирање, PATCH за делимично ажурирање, DELETE за брисање. Идемпотентност метода је кључна карактеристика: GET, PUT, DELETE су идемпотентни (вишеструко извршавање даје исти резултат), POST и PATCH нису. То је важно за обраду мрежних грешака, када клијент не зна да ли је захтев стигао до сервера.

• GET — добијање ресурса или листе ресурса. Идемпотентан, не мијења стање сервера
• POST — креирање новог ресурса. Није идемпотентан, сваки позив креира нови ресурс
• PUT — потпуна замена ресурса. Идемпотентан, поновни позив не мијења стање након првог
• PATCH — делимично ажурирање ресурса. Делимично идемпотентан (зависи од имплементације)
• DELETE — брисање ресурса. Идемпотентан, поновно брисање враћа 404, а не грешку

Статусни кодови HTTP су неодвојиви део REST API. Сваки код има одређено значење: 200 OK за успешан GET, 201 Created за POST, 204 No Content за DELETE без тела одговора, 400 Bad Request за невалидне податке, 401 Unauthorized за недостатак аутентификације, 404 Not Found за непостојеће ресурса. Правилно коришчење статусних кодова чини API самодокументирајућим и поједностављује дебагирање.

Формати података: JSON и други

JSON (JavaScript Object Notation) — основни формат преношења података у REST API. Његова популарност се објашњава једноставношћу, читљивошћу за људе и изворном подршком у JavaScript-у. JSON се преноси са заглављем Content-Type: application/json. Алтернативе укључују XML (обиман, застарео), YAML (практичан за конфигурацију, ређи за API) и Protocol Buffers (бинарни, ефикасан за системе са високим оптерећењем).

Структура JSON објекта у REST API обично укључује поља id, type и атрибуте ресурса. За колекције користи се JSON низ са метаподацима за пагинацију. Модерни REST API следе спецификацију JSON:API (jsonapi.org) или JSON Schema за валидацију одговора. Коришчење јединственог формата података поједностављује развој клијентских библиотека и генерацију документације.

Примјер JSON одговора за листу корисника:

{
    "data": [
        {
            "id": 1,
            "name": "Ана Петрова",
            "email": "anna@example.com"
        }
    ],
    "meta": {
        "total": 42,
        "page": 1,
        "per_page": 10
    }
}

Избор формата преношења података утиче на перформансе мобилне апликације. JSON се компримира путем GZIP за 70–80%, што га чини прихватљивим за већину сценарија. За апликације у реалном времену са великим обимом података (стриминг, игре) препоручује се прелазак на бинарне протоколе или коришчење WebSocket у комбинацији са Protocol Buffers.

Примјери REST API захтева

Размотримо практичне примјере рада са REST API на страни мобилне апликације. Као примјер, узећемо API за рад са порућбинама у интернет продавници. За сваку HTTP методу приказани су захтев и очекивани одговор сервера. Примјери приказују типичну структуру RESTful API која се користи у мобилном развоју.

GET — добијање листе порућбина

Захтев за добијање свих порућбина корисника са пагинацијом. Одговор садржи низ објеката порућбина и метаинформације за навигацију по страницама. Параметри page и per_page се преносе путем query string-а.

// Retrofit интерфејс за 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 — креирање нове порућине

Креирање нове порућине путем POST захтева. Сервер враћа статус 201 Created и креирани објекат у телу одговора. Важно: креирање се врши на колекцији /api/v1/orders, а не на конкретном ресурсу — то је стандардни RESTful образац.

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

// Примјер тела захтева
data class CreateOrderRequest(
    val productId: String,
    val quantity: Int,
    val addressId: String
)

DELETE — брисање порућине

Брисање ресурса се врши методом DELETE на конкретном URL-у порућине. Успешно брисање враћа 204 No Content. Идемпотентност DELETE значи да ће поновни захтев на исти URL вратити 404 Not Found, што се исправно обрађује на клијенту.

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

// Коришћење у ViewModel
fun removeOrder(orderId: String) {
    viewModelScope.launch {
        val response = api.deleteOrder(orderId)
        if (response.isSuccessful) {
            showSuccess()
        }
    }
}

Ови примјери приказују типичну имплементацију REST API на страни Android-а коришћећем Retrofit и Kotlin Coroutines. За iOS апликације, аналогну улогу има URLSession или библиотека Alamofire у комбинацији са Codable протоколима. Структура REST API остаје иста без обзира на платформу — мења се само начин извршавања захтева.

RESTful API дизајн: практичне препоруке

Пројектовање квалитетног RESTful API захтева поштовање конвенција које API чине интуитивним за програмере. Ресурси треба да се именују именицама у множини (/users, /orders, /products), HTTP методе треба да одражавају операције, а URL — хијерархијску структуру. Грешке треба да враћају стандардизовани JSON са кодом и поруком, а не само HTTP статус. Поштовање ових конвенција смањује праг уласка за нове програмере и поједностављује интеграцију.

• Именовање ресурса — множина, kebab-case: /api/v1/user-orders, не /api/v1/getUserOrders
• Филтрирање и сортирање — путем query параметара: ?status=active&sort=created_at:desc
• Пагинација — cursor-based за велике скупове, page-based за мале
• Верзионисање — путем URL (/api/v2/) или заглавља Accept-Version
• Грешке — јединствени формат: { "error": { "code": "VALIDATION_ERROR", "message": "..." } }
• Rate limiting — заглавља X-RateLimit-Remaining и Retry-After

Једна од честих грешака у пројектовању REST API је прекомерно угнијежђивање ресурса. Уместо /users/1/orders/5/items/3 боље је користити платну структуру са query параметрима: /items?order_id=5&user_id=1. То поједностављује кеширање, не захтева подршку дугачких путања на серверу и лакше се документира. Платна архитектура је такође компатибилнија са graph-based упитима при преласку на GraphQL у будућности.

Сигурност REST API се остварује кроз аутентификацију (JWT, OAuth 2.0) и ауторизацију на нивоу ресурса. Сваки захтев треба да провјери да ли корисник има приступ траженом ресурсу. HTTPS је обавезан — без енкрипције, токени и подаци се преносе у отвореном тексту. За мобилне апликације препоручује се коришћење OAuth 2.0 са PKCE (Proof Key for Code Exchange) ради сигурног добијања токена.

Верзионисање и кеширање

Верзионисање REST API је потребно за уназад компатибилност при променама. Најчешћи приступи: верзија у URL (/api/v1/orders), верзија у заглављу (Accept: application/vnd.myapi.v1+json) и верзија у query параметру (?api_version=1). URL верзионисање је најпопуларнији метод, јер је јасно видљив у логовима и документацији. Ипак, он крши принцип REST-а о јединственом URL-у ресурса.

Кеширање у REST API се реализује кроз HTTP заглавља Cache-Control, ETag и Last-Modified. GET захтеви означени као кешираљиви могу да се опслужују из кеша браузера или проксија без позива сервера. За мобилне апликације, кеширање је посебно важно — смањује потрошњу саобраћаја и убрзава приказ претходно учитаних података при слабој вези. ETag је хеш садржаја одговора: клијент га шаље у If-None-Match, а сервер враћа 304 Not Modified ако се подаци нису промијењени.

Савремене алтернативе REST API укључују GraphQL (флексибилан одабир података од стране клијента) и gRPC (бинарни протокол на HTTP/2 за микросервисе). Ипак, REST остаје главни стандард за јавне API-је захваљујући својој једноставности, универзалности и широкој подршци алата. Избор између REST-а и алтернатива зависи од конкретних захтева пројекта: сложености упита, обима података, захтева за ажурирање у реалном времену.