OpenAPI Schema Object
OpenAPI 3.1 Schema Object описує структуру payload через JSON Schema vocabulary. Список required визначає обов’язкові properties; оголошення property саме по собі не робить його обов’язковим.
Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Терміни, нюанси та джерела
OpenAPI Specification v3.1.0
Дає формальний contract для schema, types і required properties API payload.
Міграція бази даних і тестування даних → Першоджерело ↗Від manual models до specification-driven generation
Без API docs можна згенерувати POJO з observed JSON, але це лише semi-automatic recovery. З OpenAPI specification можна відтворювано генерувати models і API client через Gradle/Maven/CLI. Specification містить metadata, servers, paths, operations, schemas і response/error definitions. Swagger UI — лише projection цієї специфікації; code generator працює з machine-readable JSON/YAML.
SAST, DAST і спеціалізовані scanners
SAST аналізує codebase, configuration та infrastructure definitions без запуску повного user flow. До scope можуть входити source code, dependencies, YAML, Docker та Terraform files. DAST працює проти запущеного застосунку: генерує requests, змінює parameters, headers, authentication data й шукає небезпечну runtime behavior. OpenAPI specification може бути input для API security scanner-а. Окремі tools аналізують network traffic або вразливості, характерні для конкретної мови, cloud platform, protocol чи IoT stack. Тому pentesting швидко розгалужується на спеціалізації, а не зводиться до ручного перебору requests у Postman.
OpenAPI, JSON types і шлях даних
Автор розбирає Swagger/OpenAPI descriptions і JSON як мову обміну між clients та backend. Тип, format, required fields, arrays і dates важливі не менше за business value. Окрема тема — перетворення дат і numbers між database, backend і frontend. Якісний test design залежить від розуміння цих transformations; black-box response assertion може не показати, на якому рівні виник defect.
Що тестувати і де знайти contract
Дані, які бачить користувач, приходять з backend services, тому UI scenario часто можна розкласти на більш швидкі API checks. Спочатку треба з’ясувати API maturity: чи є specification, чи вона актуальна, як frontend реально викликає endpoints. Якщо documentation немає або їй не можна довіряти, browser DevTools/Network дає фактичні URL, method, headers, payload і response. Це джерело для discovery, але не заміна погодженого contract.
Consumer, producer і REST resources
Звична client–server model узагальнюється термінами consumer і producer. Consumer споживає дані або можливість, producer їх надає. Така мова працює не лише для browser і web server, а й для взаємодії між сервісами. Комунікація має protocol і contract. API-документації може не бути, вона може бути написаною вручну і застарілою або code-generated з анотацій у коді. У REST сутності представлені resources, а операції над ними — endpoints з HTTP-методами `GET`, `POST`, `PUT`, `DELETE`.
Gradle task: input, output і generator config
В build configuration задаються specification URL/file, output directory, generator/language, package names і config options. Окрема task спочатку отримує spec, потім генерує sources. Вихід кладеться в `build/`, а не редагується вручну. Так generator залишається build product, а не другим source of truth.
Коли backend справді простий і де ховається складність
[Дивитися з 24:35](https://www.youtube.com/watch?v=GwmAB4IvQUk&t=1475s). Простим можна вважати потік без зовнішніх інтеграцій і складних доменних правил, де запит напряму читає дозволені поля. Але навіть там можуть з'явитися GraphQL-подібні запити, складна authorization-фільтрація або performance-проблеми в database. Головний висновок: тестувальник має намалювати реальний dependency flow, з'ясувати, де виконуються authentication, authorization, billing, caching і error handling, а вже потім обирати рівні тестування та automation. Простота UI чи OpenAPI-контракту не є доказом простоти системи.