8 питань

Питання на співбесіді з HTTP

Питання рівня Junior

  1. 1. Які основні HTTP-методи ви знаєте і які з них ідемпотентні?

    Відповідь

    GET читає ресурс, POST створює або запускає дію, PUT замінює ресурс, PATCH частково оновлює, DELETE видаляє. Ідемпотентний метод при повторенні того самого запиту дає той самий стан на сервері, що й один запит. GET, PUT і DELETE ідемпотентні, а POST ні, і PATCH у загальному випадку теж ні. GET і HEAD ще й безпечні, тобто не змінюють стан.

    Додаткове питання: Як зробити повторний POST безпечним, наприклад для оплати?

    Розбір теми в курсі: HTTP і REST API

  2. 2. Які є класи HTTP-статусів? Наведіть приклади.

    Відповідь

    1xx інформаційні, 2xx успіх (200 OK, 201 Created, 204 No Content), 3xx перенаправлення (301, 302, 304 Not Modified). 4xx означають помилку клієнта: 400 некоректний запит, 401 не автентифікований, 403 доступ заборонено, 404 не знайдено. 5xx означають помилку сервера, наприклад 500 або 503. Правильний статус важливий, бо на нього спираються клієнти, кеші й моніторинг.

    Додаткове питання: Який статус повернути, якщо дані запиту валідні за форматом, але порушують бізнес-правило?

    Розбір теми в курсі: HTTP і REST API

  3. 3. Що таке REST і як правильно проєктувати URL ресурсів?

    Відповідь

    REST це архітектурний стиль, де все є ресурсами з адресою, а дії над ними виражаються HTTP-методами. URL містять іменники в множині, а не дієслова: GET /users/42, POST /users, а не /getUser. Вкладеність показує зв'язки, наприклад /users/42/orders. Сервер не зберігає стан сесії між запитами, кожен запит несе все необхідне.

    Додаткове питання: Як ви реалізуєте пагінацію і фільтрацію в REST API?

    Розбір теми в курсі: HTTP і REST API

  4. 4. Навіщо потрібні заголовки Content-Type і Accept?

    Відповідь

    Content-Type описує формат тіла повідомлення, наприклад application/json або multipart/form-data, щоб отримувач знав, як його розібрати. Accept у запиті повідомляє серверу, які формати відповіді клієнт приймає. Якщо сервер не може віддати потрібний формат, він повертає 406 Not Acceptable. Неправильний Content-Type часто призводить до того, що сервер не бачить тіло запиту.

    Додаткове питання: Які ще заголовки ви часто використовуєте в API?

    Розбір теми в курсі: HTTP і REST API

  5. 5. Чим PUT відрізняється від PATCH?

    Відповідь

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

    Додаткове питання: Чи можна створити ресурс через PUT і коли це доречно?

    Розбір теми в курсі: HTTP і REST API

Питання рівня Middle

  1. 1. Чим автентифікація через cookie-сесії відрізняється від токенів на кшталт JWT?

    Відповідь

    При сесіях сервер зберігає стан, а браузер автоматично надсилає cookie з id сесії. З прапорцями HttpOnly, Secure і SameSite cookie недоступна з JavaScript і краще захищена від XSS та CSRF. Токен клієнт зазвичай передає явно в заголовку Authorization: Bearer, а JWT містить підписані дані, тож сервер може перевірити його без сховища. Мінус JWT у тому, що відкликати його до закінчення терміну складно, тому роблять короткий access token і refresh token.

    Додаткове питання: Де безпечніше зберігати токен у браузері і чому localStorage ризикований?

    Розбір теми в курсі: HTTP і REST API

  2. 2. Що таке CORS і навіщо браузер робить preflight-запит?

    Відповідь

    Браузер за політикою same-origin блокує читання відповідей з іншого origin, тобто іншої комбінації протоколу, домену і порту. CORS дозволяє серверу явно дозволити це заголовками на кшталт Access-Control-Allow-Origin. Для непростих запитів, наприклад з PUT, DELETE або Content-Type: application/json, браузер спершу надсилає OPTIONS preflight і перевіряє дозволені методи й заголовки. CORS обмежує лише браузери, серверні клієнти його не враховують.

    Додаткове питання: Чому не можна поєднати Access-Control-Allow-Origin: * з передачею cookie?

    Розбір теми в курсі: HTTP і REST API

  3. 3. Як працює кешування в HTTP?

    Відповідь

    Сервер керує кешуванням заголовком Cache-Control: max-age задає час свіжості, no-store забороняє кешувати, no-cache дозволяє кешувати лише з перевіркою, private і public вказують, хто може кешувати. Для перевірки сервер віддає ETag або Last-Modified, а клієнт потім надсилає If-None-Match чи If-Modified-Since. Якщо ресурс не змінився, сервер відповідає 304 Not Modified без тіла. Статичні файли з хешем у назві кешують надовго з immutable.

    Додаткове питання: Як інвалідувати кеш у користувачів після деплою нової версії фронтенду?

    Розбір теми в курсі: HTTP і REST API

Тренуй ці питання

Вчи картки, відповідай текстом або голосом і отримуй оцінку AI. Потрібен вхід в акаунт.

Тренувати ці питання

Відповідай уголос і отримуй оцінку

Тут питання з еталонними відповідями. У застосунку ShortLesson ти відповідаєш сам, текстом або голосом, а AI оцінює відповідь за критеріями і ставить додаткове питання, як на справжній співбесіді.

Застосунок незабаром з'явиться в магазинах.

Інші теми

Розділи платформи