Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
У відео в завантаженій OpenAPI specification знайдено operation ID getProjects.
Поточна публічна документація Testomat.io підтверджує endpoint отримання проєктів, але не показує operationId=getProjects; цей identifier лишається властивістю snapshot із відео, доки його не підтверджено в current OpenAPI document.
OpenAPI 3.1 Schema Object описує структуру payload через JSON Schema vocabulary. Список required визначає обов’язкові properties; оголошення property саме по собі не робить його обов’язковим.
Library і CLI utility, що генерує Pydantic-моделі з OpenAPI 3, JSON Schema та інших структурованих sources.
2. API автоматизація одразу правильно, MVC, pydantic →Підтверджує й актуалізує поняття уроку, пов’язані з operationId.
3. API preconditions → Першоджерело ↗Дає формальний contract для schema, types і required properties API payload.
Міграція бази даних і тестування даних → Першоджерело ↗Необов’язковий OpenAPI identifier; якщо він присутній, має бути case-sensitive і унікальним серед operations, а інструменти можуть використовувати його як стабільне ім’я.
3. API preconditions →OpenAPI JSON/YAML можна передати AI-агенту, але велика специфікація легко перевищує корисний контекст. Не варто просити згенерувати клієнт для всього API, якщо зараз потрібна одна операція. Практичний процес: знайти в документації endpoint, його `operationId` (`getProjects`), спосіб авторизації, parameters і response schema; потім дати агенту лише цей контракт і конкретну задачу.
Замість того щоб працювати з response як із набором рядків і dictionary keys, пропонується описати його через `Pydantic`. Так тест перевіряє не лише наявність значення, а й структуру, типи та обов’язковість полів. Джерелом схеми може бути `OpenAPI`-специфікація Testomat.io. Якщо документації немає, модель можна початково згенерувати з реального JSON через JSON-to-Pydantic і потім відредагувати. Автор одразу попереджає: навіть офіційна специфікація може відставати від фактичної response schema.
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.
Звична client–server model узагальнюється термінами consumer і producer. Consumer споживає дані або можливість, producer їх надає. Така мова працює не лише для browser і web server, а й для взаємодії між сервісами. Комунікація має protocol і contract. API-документації може не бути, вона може бути написаною вручну і застарілою або code-generated з анотацій у коді. У REST сутності представлені resources, а операції над ними — endpoints з HTTP-методами `GET`, `POST`, `PUT`, `DELETE`.
До проєкту додаються `pydantic` і `datamodel-code-generator`. Генератор приймає локальну схему або URL, обирає `Pydantic BaseModel` як output і зберігає Python-моделі у `src/api/models`. Довгу CLI-команду краще винести в project configuration: там фіксуються input, output, версія Python і правила aliases. Згенерований файл — це стартова точка, а не готова доменна модель: автоматичні назви і надто загальні класи ще доведеться уточнювати.
[Дивитися з 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-контракту не є доказом простоти системи.