スキル一覧に戻る
tinkermonkey

layer-06-api

by tinkermonkey

A full-stack metadata framework for describing software architecture, workflows, and observability

1🍴 0📅 2026年1月24日
GitHubで見るManusで実行

SKILL.md


name: LAYER_06_API description: Expert knowledge for API Layer modeling in Documentation Robotics triggers: [ "OpenAPI", "REST API", "endpoint", "operation", "swagger", "API specification", "HTTP method", "request", "response", ] version: 0.6.0

API Layer Skill

Layer Number: 06 Specification: Metadata Model Spec v0.6.0 Purpose: Defines REST API contracts using OpenAPI 3.0, specifying endpoints, operations, request/response schemas, and security requirements.


Layer Overview

The API Layer captures API contracts:

  • OPERATIONS - HTTP methods on paths (GET, POST, PUT, DELETE, PATCH)
  • SCHEMAS - Request/response data structures
  • SECURITY - Authentication and authorization schemes
  • DOCUMENTATION - API metadata, descriptions, examples
  • INTEGRATION - Links to business services, application services, data models

This layer uses OpenAPI 3.0.3 (de facto industry standard) with custom extensions for cross-layer traceability.

Central Entity: The Operation (HTTP method on a path) is the core modeling unit.


Entity Types

Core OpenAPI Entities (13 entities)

Entity TypeDescription
OpenAPIDocumentRoot of an OpenAPI specification file (version 3.0.3)
InfoMetadata about the API (title, description, version, contact, license)
ServerServer where the API is available (with URL and variables)
PathsAvailable API endpoints and operations
PathItemOperations available on a path
OperationSingle API operation (HTTP method on a path) - CENTRAL ENTITY
ParameterParameter for an operation (locations: query, header, path, cookie)
RequestBodyRequest payload for an operation
ResponsesPossible responses from an operation
ResponseSingle response definition with status code
MediaTypeMedia type and schema for request/response body
ComponentsReusable component definitions (schemas, responses, parameters, examples, security schemes)
SchemaData type definition (JSON Schema subset)

Metadata Entities (11 entities)

Entity TypeDescription
TagMetadata label for grouping operations
ExternalDocumentationReference to external documentation
ContactContact information for API owner
LicenseLegal license for API
ServerVariableVariable placeholder in server URL templates
HeaderHTTP header parameters for requests/responses
LinkRelationship between API responses and subsequent operations (HATEOAS)
CallbackWebhook or callback URL pattern
ExampleSample values for documentation and testing
EncodingSerialization details for multipart content
SecuritySchemeSecurity mechanism (types: apiKey, http, oauth2, openIdConnect)

Supporting Entities (3 entities)

Entity TypeDescription
OAuthFlowsConfiguration for OAuth 2.0 flows
ConditionLogical expression for policy evaluation
RetentionPolicyData retention policies
ValidationRuleData validation constraints

Intra-Layer Relationships

Composition Relationships (Part cannot exist without whole)

SourcePredicateTargetExample
OpenAPIDocumentcomposesInfoDocument has metadata
OpenAPIDocumentcomposesPathsDocument defines endpoints
OpenAPIDocumentcomposesComponentsDocument has reusable components
PathscomposesPathItemPaths contain path items
PathItemcomposesOperationPath has HTTP methods
PathItemcomposesParameterPath-level parameters
OperationcomposesParameterOperation-specific parameters
OperationcomposesRequestBodyRequest payload definition
OperationcomposesResponsesResponse definitions
ResponsescomposesResponseIndividual status responses
RequestBodycomposesMediaTypeRequest content types
ResponsecomposesMediaTypeResponse content types
ResponsecomposesHeaderResponse headers
ResponsecomposesLinkHATEOAS links
MediaTypecomposesSchemaData structure
MediaTypecomposesExampleSample data
MediaTypecomposesEncodingSerialization details
ComponentscomposesSchemaReusable schemas
ComponentscomposesResponseReusable responses
ComponentscomposesParameterReusable parameters
ComponentscomposesExampleReusable examples
ComponentscomposesRequestBodyReusable request bodies
ComponentscomposesHeaderReusable headers
ComponentscomposesSecuritySchemeSecurity definitions
ComponentscomposesLinkReusable links
ComponentscomposesCallbackReusable callbacks
InfocomposesContactAPI owner contact
InfocomposesLicenseAPI license
SecuritySchemecomposesOAuthFlowsOAuth2 configuration

Aggregation Relationships (Part can exist independently)

SourcePredicateTargetExample
OpenAPIDocumentaggregatesServerAPI deployment servers
OpenAPIDocumentaggregatesTagOperation tags
OpenAPIDocumentaggregatesSecurityRequirementGlobal security
ServeraggregatesServerVariableURL template variables
PathItemaggregatesParameterShared parameters
OperationaggregatesCallbackWebhooks
OperationaggregatesSecurityRequirementOperation-level security

Reference Relationships

SourcePredicateTargetExample
SchemareferencesSchemaSchema $ref to another schema
ParameterreferencesSchemaParameter uses schema
HeaderreferencesSchemaHeader uses schema
LinkreferencesOperationLink points to operation (operationId)
CallbackreferencesPathItemCallback references path definition
OperationreferencesTagOperation tagged for grouping
TagreferencesExternalDocumentationTag links to external docs
OpenAPIDocumentreferencesExternalDocumentationDocument links to external docs
EncodingreferencesHeaderEncoding uses headers

Specialization Relationships

SourcePredicateTargetExample
SchemaspecializesSchemaSchema inheritance (allOf, oneOf, anyOf)

Behavioral Relationships

SourcePredicateTargetExample
OperationtriggersCallbackOperation invokes webhook
SecuritySchemeservesOperationSecurity scheme protects operation

Association Relationships

SourcePredicateTargetExample
Contactassociated-withOpenAPIDocumentContact info for API
Licenseassociated-withOpenAPIDocumentLegal license

Cross-Layer References

Outgoing References (API → Other Layers)

OpenAPI specification includes custom extensions (x-* properties) for cross-layer traceability:

Target LayerExtension PropertyExample
Layer 1 (Motivation)x-supports-goalsOperation supports business goals
Layer 1 (Motivation)x-fulfills-requirementsOperation fulfills functional requirements
Layer 1 (Motivation)x-governed-by-principlesOperation follows architectural principles
Layer 1 (Motivation)x-constrained-byOperation subject to constraints (GDPR, HIPAA, SOX)
Layer 2 (Business)x-business-service-refOperation realizes business service
Layer 2 (Business)x-business-interface-refOperation exposed via business interface
Layer 4 (Application)x-archimate-refOpenAPI document realizes ApplicationService
Layer 7 (Data Model)schema.$refSchema references JSON Schema definition
Layer 3 (Security)x-security-resourceOperation protected by SecureResource
Layer 3 (Security)x-required-permissionsOperation requires specific permissions
Layer 3 (Security)x-rate-limitRate limiting configuration
Layer 11 (APM)x-apm-business-metricsOperation tracked by business metrics
Layer 11 (APM)x-apm-sla-target-latencyExpected response time (e.g., "100ms")
Layer 11 (APM)x-apm-sla-target-availabilityExpected availability (e.g., "99.9%")
Layer 11 (APM)x-apm-traceDistributed tracing enabled
Layer 11 (APM)x-apm-criticalityBusiness criticality (critical, high, medium, low)

Incoming References (Lower Layers → API)

Lower layers reference API layer to show implementation and data structure.


Codebase Detection Patterns

Pattern 1: FastAPI Python

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel

app = FastAPI(
    title="User Management API",  # OpenAPIDocument: Info.title
    description="API for managing user accounts",  # Info.description
    version="1.0.0"  # Info.version
)

class UserCreateRequest(BaseModel):  # Schema (RequestBody)
    username: str
    email: str
    full_name: str

class UserResponse(BaseModel):  # Schema (Response)
    user_id: str
    username: str
    email: str
    created_at: datetime

@app.post(
    "/api/users",  # PathItem + Operation (POST)
    response_model=UserResponse,  # Response schema
    status_code=201,  # Response status
    tags=["Users"],  # Tag
    summary="Create a new user",  # Operation.summary
    description="Creates a new user account with the provided details"  # Operation.description
)
async def create_user(user: UserCreateRequest) -> UserResponse:  # RequestBody + Response
    """
    x-business-service-ref: business/service/user-management
    x-apm-sla-target-latency: 200ms
    x-required-permissions: users.write
    """
    pass

Maps to:

  • OpenAPIDocument: "User Management API"
  • PathItem: "/api/users"
  • Operation: "POST /api/users"
  • RequestBody: MediaType (application/json) with Schema (UserCreateRequest)
  • Response: 201 with Schema (UserResponse)
  • Tag: "Users"

Pattern 2: Express.js TypeScript

import express from "express";
import { body, param, query, validationResult } from "express-validator";

const router = express.Router();

/**
 * @openapi
 * /api/orders/{orderId}:
 *   get:
 *     summary: Get order by ID
 *     description: Retrieves a single order by its unique identifier
 *     tags:
 *       - Orders
 *     parameters:
 *       - name: orderId
 *         in: path
 *         required: true
 *         schema:
 *           type: string
 *           format: uuid
 *     responses:
 *       200:
 *         description: Order found
 *         content:
 *           application/json:
 *             schema:
 *               $ref: '#/components/schemas/Order'
 *       404:
 *         description: Order not found
 *     x-business-service-ref: business/service/order-management
 *     x-apm-sla-target-latency: 100ms
 *     x-apm-criticality: high
 */
router.get("/api/orders/:orderId", param("orderId").isUUID(), async (req, res) => {
  // Implementation
});

Maps to:

  • PathItem: "/api/orders/{orderId}"
  • Operation: "GET /api/orders/{orderId}"
  • Parameter: "orderId" (in: path, type: string, format: uuid)
  • Response: 200 with schema reference
  • Response: 404 error response
  • Custom extensions: x-business-service-ref, x-apm-sla-target-latency, x-apm-criticality

Pattern 3: Spring Boot Java

@RestController
@RequestMapping("/api/products")
@Tag(name = "Products", description = "Product management operations")
public class ProductController {

    @Operation(
        summary = "List products",
        description = "Returns a paginated list of products",
        extensions = {
            @Extension(name = "x-apm-sla-target-latency", properties = @ExtensionProperty(name = "latency", value = "150ms")),
            @Extension(name = "x-required-permissions", properties = @ExtensionProperty(name = "permissions", value = "products.read"))
        }
    )
    @ApiResponses({
        @ApiResponse(
            responseCode = "200",
            description = "Products retrieved successfully",
            content = @Content(
                mediaType = "application/json",
                schema = @Schema(implementation = ProductListResponse.class)
            )
        )
    })
    @GetMapping
    public ResponseEntity<ProductListResponse> listProducts(
        @Parameter(description = "Page number", example = "1") @RequestParam(defaultValue = "1") int page,
        @Parameter(description = "Page size", example = "20") @RequestParam(defaultValue = "20") int size
    ) {
        // Implementation
    }
}

Maps to:

  • PathItem: "/api/products"
  • Operation: "GET /api/products"
  • Parameters: "page" (query), "size" (query)
  • Response: 200 with ProductListResponse schema
  • Tag: "Products"
  • Custom extensions

Pattern 4: OpenAPI YAML Definition

openapi: 3.0.3
info:
  title: Payment Processing API
  description: API for processing customer payments
  version: 2.1.0
  contact:
    name: API Support
    email: api-support@example.com
  license:
    name: MIT
    url: https://opensource.org/licenses/MIT
  x-governed-by-principles:
    - motivation/principle/api-first-design
    - motivation/principle/security-by-design

servers:
  - url: https://api.example.com/v2
    description: Production server
  - url: https://staging-api.example.com/v2
    description: Staging server

paths:
  /payments:
    post:
      summary: Process payment
      description: Processes a payment transaction
      operationId: processPayment
      tags:
        - Payments
      security:
        - oauth2: [payments.write]
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: "#/components/schemas/PaymentRequest"
            examples:
              credit-card:
                $ref: "#/components/examples/CreditCardPayment"
      responses:
        "201":
          description: Payment processed successfully
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/PaymentResponse"
        "400":
          $ref: "#/components/responses/BadRequest"
        "401":
          $ref: "#/components/responses/Unauthorized"
      x-business-service-ref: business/service/payment-processing
      x-apm-sla-target-latency: 500ms
      x-apm-sla-target-availability: 99.99%
      x-apm-criticality: critical
      x-required-permissions:
        - payments.write
      x-rate-limit:
        requests: 100
        window: 60s

components:
  schemas:
    PaymentRequest:
      type: object
      required:
        - amount
        - currency
        - payment_method
      properties:
        amount:
          type: number
          format: double
          minimum: 0.01
          example: 99.99
        currency:
          type: string
          enum: [USD, EUR, GBP]
          example: USD
        payment_method:
          $ref: "#/components/schemas/PaymentMethod"

    PaymentResponse:
      type: object
      properties:
        transaction_id:
          type: string
          format: uuid
        status:
          type: string
          enum: [pending, completed, failed]
        timestamp:
          type: string
          format: date-time

  securitySchemes:
    oauth2:
      type: oauth2
      flows:
        authorizationCode:
          authorizationUrl: https://auth.example.com/oauth/authorize
          tokenUrl: https://auth.example.com/oauth/token
          scopes:
            payments.read: Read payment information
            payments.write: Process payments

  responses:
    BadRequest:
      description: Invalid request
      content:
        application/json:
          schema:
            $ref: "#/components/schemas/Error"

  examples:
    CreditCardPayment:
      value:
        amount: 99.99
        currency: USD
        payment_method:
          type: credit_card
          card_number: "4111111111111111"

Modeling Workflow

Step 1: Create OpenAPI Document

# Create the API specification document
dr add api document "payment-api" \
  --properties version=3.0.3,title="Payment Processing API",api-version=2.1.0 \
  --description "API for processing customer payments"

# Add API metadata
dr add api info "payment-api-info" \
  --properties title="Payment Processing API",version=2.1.0,contact-email=api@example.com \
  --description "API metadata and contact information"

# Link to motivation layer
dr relationship add "api/document/payment-api" \
  governed-by "motivation/principle/api-first-design"

Step 2: Define Servers

# Production server
dr add api server "production-server" \
  --properties url=https://api.example.com/v2,description="Production server" \
  --description "Production API server"

# Staging server
dr add api server "staging-server" \
  --properties url=https://staging-api.example.com/v2,description="Staging server" \
  --description "Staging API server"

Step 3: Define Security Schemes

# OAuth2 security
dr add api security-scheme "oauth2-auth" \
  --properties type=oauth2,flow=authorizationCode,authorization-url=https://auth.example.com/oauth/authorize,token-url=https://auth.example.com/oauth/token \
  --description "OAuth2 authorization code flow"

# API Key security
dr add api security-scheme "api-key-auth" \
  --properties type=apiKey,in=header,name=X-API-Key \
  --description "API key authentication"

Step 4: Define Schemas (Data Models)

# Request schema
dr add api schema "payment-request" \
  --properties type=object,required=amount:currency:payment_method \
  --description "Payment request payload"

# Response schema
dr add api schema "payment-response" \
  --properties type=object \
  --description "Payment processing response"

# Link to data model layer
dr relationship add "api/schema/payment-request" \
  references "data-model/schema/payment-request"

Step 5: Define Operations (Core Entities)

# POST operation
dr add api operation "process-payment" \
  --properties path=/payments,method=POST,operation-id=processPayment \
  --description "Processes a payment transaction"

# Add custom extensions for cross-layer traceability
dr add api operation "process-payment" \
  --properties x-business-service-ref=business/service/payment-processing,x-apm-sla-target-latency=500ms,x-apm-sla-target-availability=99.99%,x-apm-criticality=critical,x-required-permissions=payments.write

# GET operation
dr add api operation "get-payment" \
  --properties path=/payments/{paymentId},method=GET,operation-id=getPayment \
  --description "Retrieves payment details by ID"

Step 6: Define Parameters

# Path parameter
dr add api parameter "payment-id-param" \
  --properties name=paymentId,in=path,required=true,type=string,format=uuid \
  --description "Payment transaction ID"

# Query parameter
dr add api parameter "status-filter" \
  --properties name=status,in=query,required=false,type=string,enum=pending:completed:failed \
  --description "Filter payments by status"

# Link parameter to operation
dr relationship add "api/operation/get-payment" \
  has-parameter "api/parameter/payment-id-param"

Step 7: Define Request/Response Bodies

# Request body
dr add api request-body "payment-request-body" \
  --properties required=true,content-type=application/json \
  --description "Payment request payload"

# Link request body to schema
dr relationship add "api/request-body/payment-request-body" \
  uses-schema "api/schema/payment-request"

# Response
dr add api response "payment-success-response" \
  --properties status-code=201,description="Payment processed successfully" \
  --description "Successful payment response"

# Link response to schema
dr relationship add "api/response/payment-success-response" \
  uses-schema "api/schema/payment-response"

Step 8: Define Tags for Organization

# Add tags
dr add api tag "payments" \
  --properties name=Payments \
  --description "Payment processing operations"

dr add api tag "refunds" \
  --properties name=Refunds \
  --description "Refund operations"

# Tag operations
dr relationship add "api/operation/process-payment" \
  tagged-with "api/tag/payments"

Step 9: Cross-Layer Integration

# Link to business layer
dr relationship add "api/operation/process-payment" \
  realizes "business/service/payment-processing"

# Link to application layer
dr relationship add "api/document/payment-api" \
  realizes "application/service/payment-api"

# Link to security layer
dr relationship add "api/operation/process-payment" \
  protected-by "security/secure-resource/payment-api"

# Link to motivation layer
dr relationship add "api/operation/process-payment" \
  supports "motivation/goal/reduce-checkout-time"

# Link to APM layer
dr relationship add "api/operation/process-payment" \
  tracked-by "apm/metric/payment-processing-latency"

Step 10: Validate and Export

# Validate API layer
dr validate --layer api

# Export to OpenAPI YAML
dr export openapi --output payment-api.yaml

# Validate exported OpenAPI with external tools
spectral lint payment-api.yaml

Operation-Level SLA Patterns

Different operations have different SLA targets:

# Search operation: fast response
x-apm-sla-target-latency: "50ms"
x-apm-sla-target-availability: "99.9%"
x-apm-criticality: "high"

# Write operation: moderate latency
x-apm-sla-target-latency: "200ms"
x-apm-sla-target-availability: "99.95%"
x-apm-criticality: "critical"

# Batch operation: longer latency acceptable
x-apm-sla-target-latency: "10s"
x-apm-sla-target-availability: "99.5%"
x-apm-criticality: "medium"

# Reporting: can be slower
x-apm-sla-target-latency: "5s"
x-apm-sla-target-availability: "99%"
x-apm-criticality: "low"

Best Practices

  1. Operation is the Central Entity - Model operations, not just paths
  2. Use OpenAPI 3.0.3 - Latest stable version with broad tooling support
  3. Tag Operations - Organize operations by domain or resource
  4. Define Reusable Components - Schemas, responses, parameters in Components section
  5. Document Examples - Include request/response examples for testing and documentation
  6. Security at Operation Level - Different operations can have different security requirements
  7. Link to Business Services - Use x-business-service-ref for traceability
  8. Define SLA Targets - Use x-apm-sla-target-* for monitoring
  9. Version APIs Properly - Use semantic versioning (major.minor.patch)
  10. Generate from Code - Use FastAPI, NestJS decorators, or Springdoc to auto-generate OpenAPI specs

OpenAPI Tooling Ecosystem

Generation Tools

  • FastAPI (Python) - Auto-generates OpenAPI from Python decorators
  • NestJS (TypeScript) - Swagger module for OpenAPI generation
  • Springdoc (Java) - OpenAPI 3 for Spring Boot applications
  • Express + swagger-jsdoc (Node.js) - Generate from JSDoc comments

Validation Tools

  • Spectral - OpenAPI linter and validator
  • openapi-validator - IBM's OpenAPI validator
  • swagger-cli - Validate and bundle OpenAPI specs

Documentation Tools

  • Swagger UI - Interactive API documentation
  • Redoc - Clean, customizable API documentation
  • Postman - Import OpenAPI for API testing

Code Generation Tools

  • OpenAPI Generator - Generate client SDKs and server stubs
  • swagger-codegen - Legacy code generation tool
  • oapi-codegen (Go) - Generate Go server/client from OpenAPI

Validation Tips

IssueCauseFix
Missing OperationsPaths defined but no operationsAdd HTTP methods (GET, POST, etc.)
Unlinked SchemasSchemas not referenced by operationsLink schemas to request/response bodies
Missing SecurityOperations lack security requirementsAdd securitySchemes and apply to operations
No Cross-Layer LinksAPI not linked to business/applicationAdd x-business-service-ref and x-archimate-ref
Missing SLA TargetsOperations lack performance targetsAdd x-apm-sla-target-* extensions
Untagged OperationsOperations not organized by tagsAdd tags for grouping
No ExamplesSchemas lack examplesAdd example values for documentation
Invalid OpenAPISpec doesn't validateUse Spectral or openapi-validator

Quick Reference

Add Commands:

dr add api document <name> --properties version=3.0.3,title=<title>
dr add api operation <name> --properties path=<path>,method=<method>
dr add api schema <name> --properties type=<type>
dr add api parameter <name> --properties name=<name>,in=<location>
dr add api security-scheme <name> --properties type=<type>
dr add api tag <name> --properties name=<display-name>

Relationship Commands:

dr relationship add <operation> uses-schema <schema>
dr relationship add <operation> has-parameter <parameter>
dr relationship add <operation> tagged-with <tag>
dr relationship add <schema> references <schema>

Cross-Layer Commands:

dr relationship add api/<operation> realizes business/<service>
dr relationship add api/<document> realizes application/<service>
dr relationship add api/<schema> references data-model/<schema>
dr relationship add api/<operation> protected-by security/<resource>
dr relationship add api/<operation> supports motivation/<goal>

Export Commands:

dr export openapi --output api-spec.yaml
dr export openapi --layer api --format json --output api-spec.json

Validation Commands:

dr validate --layer api
spectral lint api-spec.yaml
swagger-cli validate api-spec.yaml

Custom Extension Reference

Documentation Robotics defines custom OpenAPI extensions for cross-layer traceability:

# Motivation Layer Links
x-supports-goals: [motivation/goal/id1, motivation/goal/id2]
x-fulfills-requirements: [motivation/requirement/id1]
x-governed-by-principles: [motivation/principle/id1]
x-constrained-by: [motivation/constraint/id1]

# Business Layer Links
x-business-service-ref: business/service/id
x-business-interface-ref: business/interface/id

# Application Layer Links
x-archimate-ref: application/service/id

# Security Layer Links
x-security-resource: security/secure-resource/id
x-required-permissions: [users.read, users.write]
x-rate-limit:
  requests: 100
  window: 60s

# APM Layer Links
x-apm-business-metrics: [apm/metric/id1]
x-apm-sla-target-latency: "100ms"
x-apm-sla-target-availability: "99.9%"
x-apm-trace: true
x-apm-criticality: "high" # critical, high, medium, low

These extensions enable full traceability from API operations to business goals, requirements, security controls, and monitoring metrics.


Summary

The API Layer is the contract layer - it defines HOW external consumers interact with your system. Every operation should:

  1. Be linked to a business service (traceability)
  2. Have clear request/response schemas
  3. Define security requirements
  4. Specify SLA targets for monitoring
  5. Include examples for documentation and testing

Use OpenAPI 3.0.3 as the foundation, leverage auto-generation tools from your framework, and extend with custom properties for full cross-layer integration.

スコア

総合スコア

60/100

リポジトリの品質指標に基づく評価

SKILL.md

SKILL.mdファイルが含まれている

+20
LICENSE

ライセンスが設定されている

+10
説明文

100文字以上の説明がある

0/10
人気

GitHub Stars 100以上

0/15
最近の活動

3ヶ月以内に更新がある

0/10
フォーク

10回以上フォークされている

0/5
Issue管理

オープンIssueが50未満

+5
言語

プログラミング言語が設定されている

+5
タグ

1つ以上のタグが設定されている

0/5

レビュー

💬

レビュー機能は近日公開予定です