It contains key summary information on the state-of-the-art interface collaboration architecture that creates an API Contract, which is a promise to connect planning and development, based on the requirements definition and screen definition, identifies inconsistencies and missing items between each document, and automates analysis and testing of UI and API dependency impacts due to changes.
Errors in understanding between planning, design, and development at the project site directly lead to database omission and loss of consistency. Find out why ensuring consistency at the design stage is important.
Because the fields of the planning document or screen design and the actually distributed API spec are different, communication errors or defects in which certain values do not appear on the screen occur one after another.
Fields are defined and developed only through verbal agreements between front-end and back-end developers, but the names (Camel vs. Snake Case) and format do not match, so the meeting is repeated every time.
Even if a single business requirement, such as price or order stage, changes, a huge analysis cost is incurred to check the scope of modifications to the API, front screen, and test code connected to it.
Unlike ChatGPT, which is limited to a single conversation context, we compare the characteristics of Codex Client, which recognizes the entire folder structure and dependency relationships between multiple files.
| Compare items | ChatGPT (General Conversational AI) | Codex Client (Workspace-based AI) |
|---|---|---|
| Context awareness | Cross-verification of actual field mapping and functional compliance between plan, screen design, and backend API specification file | By tracking the properties of multiple outputs from planning-screen-API, three-dimensional detection of ratings, missing error codes, etc. |
| API mismatch detection | Only roughly configures a one-time API code template | Self-recommendation of consistent standard naming and DB column names based on project standard terminology dictionary |
| Scope of Impact Analysis | Level of suggestions for fragmentary schema errors or hypothetical table modifications | Reverse inference on list of API specifications and screen modification areas according to subtle changes in schema (e.g. column addition) |
A list of the final products the learner produces during the Day 4 session and the purpose of those products.
Entities and relationships are extracted and rendered from the natural language plan. Mermaid ERD scripts and statements (Output: erd-schema.md)
Fragmented Korean/English planning terms defined in standard English column format Project Standards Glossary (Output: project-glossary.md)
API and screen modification list according to addition of reservation approval system (WAIT_APPROVE) Change impact analysis report (Output: change-impact-report.md)
Archives the reasons for normalization and data design decisions and rejected alternatives. Design Decision Log (DDL) (Output: design-decision-log.md)
Contains DB improvement measures for concurrent payment errors, referential integrity loss of withdrawal, and transaction rollback. Edge Case Analysis Report (Output: edge-case-analysis.md)
This is a mapping between the input values used in the practice stage and the results generated through Codex Workspace inference.
Enter meeting scenario lines to derive precise normalization relationships (1:N, 1:1) and Mermaid codes.
Based on the provided requirements definition and screen definition, please derive a list of required APIs and create a standard API contract by defining the types of Request and Response fields and English variable names.
We build a master dictionary of domain terms by comparing and analyzing the gap between Figma planning terms and DB development specifications.
Please cross-check the provided day4_requirements.md, day4_screen_definition.md, and day4_api_specification_v1.md files to find any API endpoints and fields that are inconsistent or missing from the planning requirements or screen UI design and create a review report.
Understand the scope of API and table impact when a release plan change adds an 'Approval' step to the scheduling process.
Analyze the contents of the provided API change request (day4_api_change_request.md) to derive a list of other system areas and documents affected when modifying the reservation request API, and prepare an API impact analysis that can be immediately shared with team members.
Log rejection reasons and agreements regarding normalization decisions, physical separation decisions for reservation history, etc.
Please review the provided API specification of day4_api_specification_v1.md, analyze improvements based on REST API design standards (HTTP Method usage, URL naming), consistent error handling structure, and extensibility, and write an API review report.
We audit system vulnerabilities to prevent referential integrity violations (withdrawals) and transaction collapses.
Based on the currently defined reservation and payment API specifications, please create an API test scenario and verification checklist that includes both the normal registration flow (Happy Path) and exception cases such as missing required parameters, date format errors, limit exceeded, and permission expiration.
Beyond simple text matching, it identifies the referential integrity (FK) relationships and transaction life cycle of entities and automatically deduces natural language proposals into Data Definition Language (DDL) queries and state machine rules.
We derive a master dictionary of enterprise terms by semantically clustering differently written terms (customer name vs. nickname), and synchronize the consistency of the data dictionary based on this.
We check how the data and analysis information derived from each step goes through the technical design loop to maximize quality.
This interface verification pipeline removes all errors and design inconsistencies before writing a single line of code, ensuring high-quality interface so that the front and backend can successfully build integration at once.
This is a list of topics that are great for discussion during training or to use as interview questions.
“When an error occurs, what are the pros and cons from a microservice architecture (MSA) perspective between the custom error of unconditionally sending the HTTP Status as 200 OK and displaying a detailed error code in the body (Custom Error) and using the HTTP standard Status (4xx, 5xx)?”
“When a project progresses to mid-way without creating an API mismatch detection dictionary, how does the ‘terminology debt’ cost incurred within the development team affect the actual schedule?”
This is a diagram of the overall practice tasks and missions covered on Day 4.
| Task | topic | How to use AI |
|---|---|---|
| Task 01 | Create an API contract | Automatically derive RESTful API contract specifications by analyzing the plan and screen design |
| Task 02 | API mismatch detection | Automatically detects discrepancies (missing ratings, etc.) between planning specifications and API specifications and generates reports |
| Task 03 | API change impact analysis | Track chain effects of screens and specifications that need to be linked when API parameters or status change |
| Mission 01 | API reviews and improvements | API Review Report that standardizes noun URLs, error code exception schemas, etc. to come up with improvement plans |
| Mission 02 | Create an API test scenario | Derive an exception test matrix that responds to missing essential keys and format errors as well as normal operation flow |