REST (ang. Representational State Transfer) to styl architektoniczny interfejsów API oparty na HTTP: zasoby mają adresy (URL-e), operacje wyraża się metodami protokołu (GET - pobierz, POST - utwórz, PUT/PATCH - zmień, DELETE - usuń), a serwer nie pamięta stanu klienta między żądaniami (bezstanowość). Wynik operacji komunikują kody odpowiedzi: 200 OK, 201 Created, 404 Not Found, 409 Conflict i tak dalej. API trzymające się tych zasad nazywa się RESTful.
Analityk nie projektuje API (to praca architekta i programistów), ale czyta dokumentacje API przy każdej integracji, mapuje pola między systemami i - co najważniejsze - pisze wymagania na to, co użytkownik widzi, gdy API odpowiada błędem.
Przykład (MediFlow). Integracja e-rejestracji z systemem gabinetowym 12 przychodni. GET /placowki/7/sloty?data=2026-06-15&specjalizacja=kardiolog zwraca wolne terminy; POST /wizyty tworzy rezerwację. Analityk czyta w dokumentacji, że przy próbie rezerwacji zajętego slotu API zwraca 409 Conflict - i dopisuje wymaganie: pacjent dostaje wtedy komunikat "ten termin został właśnie zajęty" plus trzy najbliższe alternatywy, a nie surowy błąd techniczny. Bez tego wymagania użytkownik zobaczyłby białą stronę dokładnie w najbardziej frustrującym momencie.
Częsta pomyłka. Nazywanie RESTem każdego API działającego po HTTP - REST to konkretny zestaw zasad, a nie synonim "API webowego" (istnieją też SOAP, GraphQL, gRPC). Druga, groźniejsza w skutkach: traktowanie kodów błędów jako "sprawy technicznej". Nieobsłużony 409, timeout czy 503 to dziura w wymaganiach analityka - bo to on odpowiada za to, co w tej sytuacji przeżyje użytkownik.