HTTP-виклик — це не виклик методу Java

1. Метод у памʼяті, HTTP у мережі

Коли ви вперше чуєте «зроби HTTP‑запит», мозок Java‑розробника часто автоматично перекладає це як «ну це ж те саме, що викликати метод, тільки через інтернет». Саме ця думка потім і створює половину дивних багів: від «чому тут немає значення» до «чому все зависло». Давайте одразу зафіксуємо межу, поки вона ще не встигла влаштувати вам вечірку з відлагоджувачем.

На цьому етапі форма обміну вже повністю видна: клієнт збирає request, надсилає його мережею і отримує response назад. У логах і інструментах це виглядає як обмін повідомленнями, а не як «стрибок у чужий код». Саме з цієї картини й випливає головний висновок лекції: HTTP-виклик не можна прирівнювати до звичайного виклику методу Java.

У Java-методу є дуже чітка механіка: JVM виконує код у межах одного процесу, з однією памʼяттю, з одними типами, з одним стеком викликів. HTTP-виклик — це не «виконати чужий метод», а надіслати структуроване повідомлення (request) в інший застосунок і дочекатися іншого структурованого повідомлення (response). Між вами та результатом з’являється цілий прошарок реальності: серіалізація даних, мережа, маршрутизація на боці сервера, формат відповіді, status, затримки, а інколи й просто «ніхто не відповів».

Щоб це закріпити не на рівні «бо так сказали», порівняймо два світи в одній таблиці.

Якщо ви тримаєте в голові цю таблицю, у вас з’являється правильний «інженерний рефлекс»: HTTP — це окремий всесвіт, і ставитися до нього потрібно інакше.

2. Локальний виклик методу в Java

Щоб відчути контраст, корисно на хвилину повернутися в звичний світ Java-методів і подивитися, наскільки там усе «домашнє». Коли ви викликаєте метод, ви не будуєте повідомлення, не думаєте про мережеві маршрути і не перевіряєте status-код результату. Ви просто кажете JVM: «виконай ось цей шматок коду» — і отримуєте значення. Усе відбувається в одній памʼяті, під контролем одного процесу.

Ось мінімальний приклад локального виклику. Він здається нудним — і це добре. Нудьга тут означає передбачуваність.

public class LocalCallExample {

    static String localTitle() {
        // Локальний метод: виконується тут же, у цій JVM
        return "Clean Code";
    }

    public static void main(String[] args) {
        // Звичайний виклик методу: жодних мереж, статусів і заголовків
        String title = localTitle();
        System.out.println(title); // Clean Code
    }
}

Що тут важливо, крім очевидного?

По-перше, тип результату вам відомий заздалегідь. Метод оголошено як String, отже ви отримаєте String (або застосунок упаде через exception, але мовчки повернути щось дивне метод не зобов’язаний). По-друге, усе відбувається в спільній памʼяті. Повернене значення — це об’єкт або значення, яке вже живе в тій самій JVM. Вам не потрібно його «декодувати» й «розпаковувати» з тексту.

По-третє, локальний виклик або повертає значення, або кидає виняток. І цей виняток — частина вашої програми: ви можете зловити його try/catch, подивитися stack trace, побачити рядок, де все зламалося, і спокійно розібратися.

Нарешті, локальний метод — це «власний код». Навіть якщо він лежить в іншому пакеті (package) і його писав колега, ви все одно можете відкрити вихідний код, поставити брейкпоінт і подивитися, що відбувається. У HTTP-виклику такої розкоші зазвичай немає: ви взаємодієте з чужою системою через контракт, а не через доступ до вихідного коду й відлагоджувача.

3. HTTP-виклик: запит і відповідь

Тепер перенесімося в мережевий світ. HTTP-виклик починається не з «викликати функцію», а з «сформувати повідомлення». Ви вирішуєте, який method, який path, які headers і чи буде body. Потім ви надсилаєте це повідомлення мережею — а далі все, що відбувається на іншому боці, вже не під вашим прямим контролем.

На концептуальному рівні можна навіть описати HTTP-запит і HTTP-відповідь як прості структури даних (у реальності вони, звісно, складніші, але нам важлива ідея «це окремий об’єкт-повідомлення»).

import java.util.Map;

public record HttpRequestData(
        String method, // HTTP-метод: GET/POST/PUT/DELETE тощо
        String pathWithQuery, // Шлях і query-параметри, наприклад: /search?q=clean+code
        Map<String, String> headers, // Заголовки (метадані запиту)
        String body // Тіло запиту (корисне навантаження), часто JSON
) { }

І відповідь:

import java.util.Map;

public record HttpResponseData(
        int status, // HTTP-статус: 200, 404, 500 тощо
        Map<String, String> headers, // Заголовки відповіді (метадані відповіді)
        String body // Тіло відповіді (дані або опис помилки)
) { }

Зверніть увагу на відчуття: у локальному виклику ви чекаєте String title, а в HTTP-світі ви чекаєте конверт (response). Навіть якщо «головні дані» лежать у body, вони не існують у вакуумі: їхній зміст залежить від status і інколи від headers. Це ви вже бачили в лекції про response: однакове тіло при різних status може означати зовсім різні речі.

Щоб візуально закріпити різницю, ось спрощена схема послідовності подій під час HTTP-виклику:

sequenceDiagram
    %% Спрощена схема: request/response — це окремі повідомлення, що мандрують мережею
    participant C as "Клієнт (ваш код / інструмент)"
    participant N as "Мережа"
    participant S as "Сервер (інший застосунок)"

    C->>N: "Надіслати HTTP-запит (method + path + headers + body)"
    N->>S: "Доставити байти"
    S->>S: "Розібрати запит і вибрати обробник"
    S-->>N: "Повернути HTTP-відповідь (status + headers + body)"
    N-->>C: "Доставити байти"

Ключовий момент: ви не можете сприймати це як «викликав метод і отримав значення», бо між «викликав» і «отримав» є безліч причин, чому ви можете не отримати нічого, отримати помилковий status, отримати неочікуваний формат або отримати повільну відповідь.

4. Об’єкти vs байти: не можна «передати об’єкт по HTTP»

Наступна пастка для новачка звучить так: «Ну раз у Java я працюю з об’єктами, значить і по HTTP передам об’єкт». Усередині одного процесу це майже правда: ви передаєте посилання на об’єкт або значення. У мережі посилань на об’єкти немає, бо в іншого застосунку інша памʼять. Між застосунками мандрують байти, а отже дані доводиться перетворювати на щось переносне: текст, JSON, бінарний формат тощо.

Саме для цього в HTTP-повідомлення є body: це місце, куди ви кладете «корисне навантаження». Поки що можна думати про body як про рядок.

Порівняйте: локально ви можете повернути об’єкт…

public record Book(String title, String author) { } // Доменні дані: об’єкт у пам’яті JVM

public class LocalDomainExample {

    static Book localBook() {
        // Повертаємо об’єкт напряму: він живе в тій самій пам’яті, що й код, який викликає
        return new Book("Clean Code", "Robert C. Martin");
    }
}

…а «по HTTP» у вас найчастіше буде щось на кшталт:

public class RemoteBodyExample {

    static String remoteBody() {
        // Мережею «летять» байти: найчастіше це текст (наприклад, JSON), а не об’єкт Book
        return """
               {"title":"Clean Code","author":"Robert C. Martin"}
               """;
    }
}

Другий рядок — це не об’єкт Book. Це текст (набір символів), який за домовленістю можна інтерпретувати як книжку. І тут починається важлива робота: щоб два застосунки розуміли одне одного, вони повинні домовитися, яким саме чином текст у body описує дані. Якщо домовленість порушити, один із застосунків читатиме не те.

Навіть якщо зараз це здається дрібницею, думка проста: при локальному виклику типи захищають вас майже автоматично, а при HTTP-виклику захист з’являється лише тоді, коли ви самі дисципліновано ставитеся до контракту обміну.

5. Результат: return/exception і status/body

У локальному методі результат — це або return, або exception. У HTTP-виклику у вас є щонайменше три різні ситуації, які початківець часто змішує в одну кашу:

Перша ситуація — сервер відповів, і у вас є response. Це означає: ви отримали status, можливо headers, можливо body. Навіть якщо status говорить «помилка», це все одно повноцінна відповідь.

Друга ситуація — сервер не відповів, бо ви не змогли з’єднатися, мережа впала, адреса неправильна, з’єднання розірвано, ви не дочекалися відповіді. У цій ситуації у вас може не бути жодного HttpResponseData взагалі.

Третя ситуація — сервер відповів «нібито успішно», але body порожнє, неочікуване або не того формату. І це окрема проблема: формально відповідь є, але «даних, які ви хотіли», немає.

Спробуємо зобразити це в зовсім простому псевдокоді, не прив’язуючись до конкретного HTTP-клієнта, бо наша мета — модель у голові, а не бібліотека.

public class RemoteResultExample {

    String handle(HttpResponseData response) {
        // 1) Спочатку перевіряємо status: це «конверт», без нього не можна правильно інтерпретувати body
        if (response.status() != 200) {
            // Сервер відповів, але повідомив про помилку через HTTP-статус
            return "Сервер відповів помилкою: status=" + response.status();
        }

        // 2) Лише після успішного status має сенс читати дані з body
        return "Дані з body: " + response.body();
    }
}

Зверніть увагу: у локальному світі ви зазвичай не обгортаєте кожен виклик у перевірку if (ok). А в HTTP-світі це цілком нормальна частина життя: спочатку зрозуміти, який status, і лише потім вирішувати, як інтерпретувати body.

Саме тому мислення «HTTP-виклик ≈ метод» ламає архітектуру. Людина чекає «поверненого значення», і її дратує необхідність читати status. Але status — не «зайва бюрократія», а частина договору: сервер не зобов’язаний віддавати вам дані, він зобов’язаний чесно повідомити, що сталося.

6. Час і невизначеність у HTTP

Є ще одна річ, яка у світі методів часто непомітна: час. Локальний виклик методу — це зазвичай мікроскопічна операція порівняно з будь-яким I/O. HTTP-виклик — це I/O майже в чистому вигляді. Навіть якщо сервер працює швидко, у вас є мережа, яка любить бути непередбачуваною: то нормально, то повільно, то «ой, Wi‑Fi вирішив замислитися над сенсом життя».

Відчути це можна навіть на іграшковому прикладі. Локальний метод викликається миттєво:

public class TimingExample {

    static String localTitle() {
        // Локальна операція: жодних очікувань мережі, диска тощо
        return "Clean Code";
    }

    public static void main(String[] args) {
        // Важливо: nanoTime() — для вимірювання тривалостей, а не «поточного часу»
        long start = System.nanoTime();
        localTitle();
        long end = System.nanoTime();

        // Тут майже завжди буде «дуже маленьке число»
        System.out.println("нс = " + (end - start)); // нс = <дуже маленьке число>
    }
}

Число буде маленьким (і в різних запусках — різним), але ідея в тому, що локальний виклик вимірюється наносекундами або мікросекундами, а будь-який реальний HTTP-виклик ви відчуватимете як мілісекунди, а інколи як секунди. Це не «погана бібліотека» і не «Java гальмує». Це фізика світу: ви спілкуєтеся з іншим застосунком, часто через кілька мережевих вузлів.

Звідси проста звичка backend-розробника: до HTTP-виклику ставляться як до дорогої операції. Його не роблять «про всяк випадок», не кладуть у безглузді цикли і не очікують, що він завжди буде швидким.

7. Контракти: сигнатура і HTTP

Є ще одна причина, чому не можна прирівнювати HTTP-виклик до методу: контракт у цих світах влаштовано по-різному. У методу контрактом є його сигнатура і типи. Компілятор допомагає вам: ви змінили тип аргумента — у вас одразу червоніє половина проєкту, і це прекрасно (боляче, зате лікує).

У HTTP-контракту немає компілятора. Є домовленості: який method, який path, які headers, чи буде body, який формат даних, який status на успіх і який на помилку. Якщо ви на одній стороні змінили щось у контракті, інший бік може дізнатися про це лише в runtime, і зазвичай дізнається в най«зручніший» момент: коли користувач уже натискає кнопку, а вам уже пізно.

Порівняймо дуже прикладно:

Саме тому backend-мислення змушує вас ставитися до HTTP як до окремої дисципліни. Ви не просто віддалено викликаєте метод. Ви входите у світ домовленостей і повідомлень, де мають значення деталі, і ці деталі не можна без наслідків заховати під килим.

8. ReadLater Starter: межа систем

У нашому проєкті ReadLater Starter ця різниця виникатиме постійно, навіть якщо поки ви ще не написали жодного рядка коду для HTTP. За задумом проєкту є зовнішній каталог книжок — окремий сервіс — і є наш застосунок, який із ним спілкується. І тут важливо усвідомити: навіть якщо ви на 100% розумієте, що «зовні є API», мозок усе одно намагатиметься хитрувати і думати: «ну я ж хочу просто отримати список книжок, отже це як catalog.search()».

Правильна картина така: catalog.search() всередині нашого застосунку (якщо ви його зробите) — це локальний метод, який у певний момент сформує HTTP-запит, надішле його назовні, отримає HTTP-відповідь, перевірить status і лише потім перетворить body на щось зручне для решти програми.

Тобто всередині застосунку ви справді працюватимете методами. Але межа назовні завжди виглядатиме як «повідомлення туди — повідомлення назад». Це корисно пам’ятати навіть на побутовому рівні: коли ви бачите рядок на кшталт https://.../search?q=clean+code, це не «назва методу в інтернеті». Це частина адреси для повідомлення, яке піде в іншу систему. І як тільки ця межа стає звичною, по-іншому починають читатися і method, і path: це вже не «ім’я віддаленої функції», а частини контракту між двома системами.

Так само, коли хтось звертатиметься до нашого застосунку через HTTP (наприклад, із браузера або іншого інструмента), він не «викликатиме наш метод». Він надсилатиме request, а ми вирішуватимемо, який шматок коду має на нього відповісти, і в якому вигляді ми повернемо response.

Якщо тримати цю картину в голові, архітектура проєкту стає акуратнішою: локальний код можна проєктувати типами і методами, а зовнішні взаємодії — контрактами повідомлень.

9. Типові помилки під час HTTP-викликів

Помилка №1: думати, що HTTP-виклик «зобов’язаний повернути значення», як метод.
Новачок на рівні очікувань часто думає: якщо він «викликав», то й «повинні повернути». У HTTP-світі може прийти response з помилковим status, може прийти порожнє body, а може не прийти взагалі нічого, бо мережа або адреса підвели. Правильна звичка — спочатку прийняти реальність response або його відсутність, і лише потім говорити про дані.

Помилка №2: читати лише body і ігнорувати status.
Це майже як у житті: дивитися лише на зміст листа і ігнорувати печатку «Адресата не знайдено». Тіло відповіді саме по собі не гарантує, що запит успішний. Якщо не дивитися на status, ви можете з радістю намагатися «розпарсити» текст помилки як дані й потім довго дивуватися, чому «у мене JSON кривий».

Помилка №3: змішувати «сервер відповів помилкою» і «сервер не відповів взагалі».
Відповідь зі статусом помилки — це все одно відповідь, отже з’єднання було, протокол спрацював, сервер щось повідомив. А мережевий збій — це інша ситуація: ви навіть не дійшли до стадії отримання response. Ці випадки потребують різного мислення і, у реальному коді, різної обробки.

Помилка №4: намагатися подумки «передати об’єкт по HTTP».
Усередині JVM ви передаєте значення і посилання. По HTTP ви передаєте байти. Якщо ви не тримаєте цю межу, ви почнете будувати очікування в стилі «ну я ж надіслав Book, чому на іншому боці не Book». На іншому боці немає вашої памʼяті, ваших класів і ваших посилань — є лише те, що ви реально поклали в body.

Помилка №5: очікувати від HTTP-виклику такої самої швидкості й стабільності, як від методу.
Локальний метод — це зазвичай дуже швидко. HTTP-виклик — це I/O, а I/O може бути повільним. Якщо закласти в голові «як метод», ви почнете викликати віддалений сервіс занадто часто, занадто глибоко всередині логіки, а потім зіткнетеся з «незрозуміло звідки взялася затримка». Навіть у навчальних проєктах корисно тримати відчуття: це дорога операція.