Saltar al contenido principal

Documentación

🎯 Objetivo​

Regla​

9.1: Se debe proporcionar documentación completa, precisa, actualizada y fácil de entender para todas las APIs REST. 9.2: La documentación es un componente esencial de la API y debe tratarse con la misma rigurosidad que el código.

📖 Concepto y Definición​

Regla​

9.3: La documentación de la API debe servir como la "fuente de verdad" para los consumidores, describiendo cómo usar la API correctamente. 9.4: Es obligatorio utilizar el estándar OpenAPI Specification (OAS), preferiblemente la versión 3.x, para describir formalmente la API. 9.5: La documentación debe incluir, como mínimo:

  • Información General: Propósito de la API, audiencia, información de contacto, URL base, esquema de autenticación/autorización requerido.
  • Descripción de Endpoints: Para cada endpoint (ruta + método HTTP):
    • Descripción clara de su propósito.
    • Parámetros de ruta, consulta y encabezado (nombre, tipo, si es requerido, descripción).
    • Descripción del cuerpo de la solicitud esperado (schema, ejemplos).
    • Posibles respuestas (códigos de estado HTTP, descripción, schema del cuerpo de la respuesta si aplica, ejemplos).
    • Permisos requeridos (si aplica).
    • Indicación de idempotencia (si aplica).
  • Modelos/Schemas: Definición de las estructuras de datos JSON utilizadas en solicitudes y respuestas.
  • Versionado: Información sobre la estrategia de versionado y las versiones disponibles.
  • Manejo de Errores: Descripción del formato estándar de error (ver Sección 11).
  • Tutoriales/Guías (Recomendado): Ejemplos prácticos de flujos comunes.
  • Política de Rate Limiting (si aplica).
  • Política de Deprecación (si aplica).
  • Definición de relaciones HATEOAS personalizadas (si aplica).

🤔 ¿Por qué es Importante? / Beneficios Clave (Contexto)​

  • Facilita la Adopción: Reduce la curva de aprendizaje.
  • Reduce Errores de Integración: Clarifica el contrato de la API.
  • Mejora la Productividad del Desarrollador: Sirve como referencia rápida.
  • Promueve la Consistencia: Ayuda a mantener la coherencia del diseño.
  • Habilita Herramientas: OAS permite generar SDKs, mocks, pruebas, etc.
  • Base para Pruebas: Define las expectativas.

✅ Buenas Prácticas y Recomendaciones Clave​

Regla​

9.6: Se refuerza la Norma 9.4: El uso de OpenAPI Specification (OAS) 3.x es obligatorio. 9.7: La descripción de la API en formato OAS debe generarse preferiblemente de forma automática a partir del código fuente (ej. usando anotaciones/decorators) para asegurar que la documentación y la implementación estén sincronizadas. Se debe integrar esta generación en el proceso de CI/CD. 9.8: Si la generación automática no es factible, la especificación OAS debe mantenerse manualmente con extrema diligencia y debe ser revisada como parte del proceso de revisión de código. 9.9: La documentación debe ser accesible públicamente (si la API es pública) o internamente (si es privada) a través de una interfaz de usuario interactiva generada a partir de la especificación OAS (ej. Swagger UI, ReDoc). 9.10: Las descripciones (description, summary) en la especificación OAS deben ser claras, concisas y escritas en un lenguaje técnico preciso pero accesible. 9.11: Se deben incluir ejemplos realistas de cuerpos de solicitud y respuesta en la especificación OAS para cada endpoint y modelo. 9.12: Los schemas de los modelos deben definir claramente los tipos de datos (string, number, integer, boolean, array, object), formatos (ej. date-time, uuid, email), si son requeridos (required), y restricciones (ej. minLength, maxLength, pattern, enum). 9.13: La documentación debe actualizarse antes o al mismo tiempo que se despliegan los cambios en la API. Está prohibido tener documentación desactualizada. 9.14: Además de la referencia OAS, se recomienda encarecidamente proporcionar guías conceptuales, tutoriales paso a paso y ejemplos de código en lenguajes populares para facilitar la integración.

Don'ts (Prohibido):

  • 9.15: No se debe publicar una API sin documentación completa y precisa.
  • 9.16: No se debe dejar la documentación desactualizada respecto a la implementación.
  • 9.17: No se debe usar descripciones vagas o incompletas en la especificación OAS.
  • 9.18: No se deben omitir ejemplos realistas.
  • 9.19: No se debe asumir que el consumidor entenderá la API solo leyendo el código o la especificación OAS sin descripciones.

💡 Ejemplos Prácticos (Ilustrativos)​

Ejemplo 1: Fragmento de Especificación OAS (YAML) (Norma 9.4, 9.12)​

openapi: 3.0.3
info:
  title: API de Usuarios
  version: 1.0.0
  description: API para gestionar usuarios.
servers:
  - url: https://api.example.com/v1
paths:
  /users/{userId}:
    get:
      summary: Obtener un usuario por ID
      description: Recupera los detalles de un usuario específico.
      operationId: getUserById
      tags:
        - Usuarios
      parameters:
        - name: userId
          in: path
          required: true
          description: El ID del usuario a recuperar.
          schema:
            type: string
            format: uuid
      responses:
        '200':
          description: Detalles del usuario.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/User'
              example:
                data:
                  userId: "f47ac10b-58cc-4372-a567-0e02b2c3d479"
                  username: "johndoe"
                  email: "john.doe@example.com"
                  dateJoined: "2022-01-15T09:00:00Z"
                _links:
                  - rel: "self"
                    href: "https://api.example.com/v1/users/f47ac10b-58cc-4372-a567-0e02b2c3d479"
                    method: "GET"
                _meta:
                  timestamp: "2023-10-27T12:00:00Z"
                  version: "1.0.0"
        '404':
          description: Usuario no encontrado.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ErrorResponse' # Ref a formato de error estándar
components:
  schemas:
    User:
      type: object
      required:
        - userId
        - username
        - email
        - dateJoined
      properties:
        userId:
          type: string
          format: uuid
          description: Identificador único del usuario.
          readOnly: true # El cliente no puede enviar esto al crear/actualizar
        username:
          type: string
          description: Nombre de usuario único.
          minLength: 3
          maxLength: 50
        email:
          type: string
          format: email
          description: Dirección de correo electrónico.
        dateJoined:
          type: string
          format: date-time
          description: Fecha y hora de registro (ISO 8601 UTC).
          readOnly: true
    ErrorResponse:
      type: object
      required:
        - error
        - _meta
        - _links
      properties:
        error:
          type: object
          required:
            - status
            - error
            - message
            - code
          properties:
            status:
              type: integer
            error:
              type: string
            message:
              type: string
            code:
              type: string
            errors:
              type: array
              items:
                type: object
                properties:
                  field:
                    type: string
                  message:
                    type: string
        _meta:
          type: object
          required:
            - timestamp
            - version
          properties:
            timestamp:
              type: string
              format: date-time
            version:
              type: string
        _links:
          type: array
          items:
            type: object
            required:
              - rel
              - href
              - method
            properties:
              rel:
                type: string
              href:
                type: string
              method:
                type: string
                enum: [GET, POST, PUT, DELETE, PATCH]

    SuccessResponse:
      type: object
      required:
        - data
        - _meta
        - _links
      properties:
        data:
          type: object
        _meta:
          type: object
          required:
            - timestamp
            - version
          properties:
            timestamp:
              type: string
              format: date-time
            version:
              type: string
            pagination:
              type: object
              properties:
                page:
                  type: integer
                perPage:
                  type: integer
                totalPages:
                  type: integer
                totalItems:
                  type: integer
        _links:
          type: array
          items:
            type: object
            required:
              - rel
              - href
              - method
            properties:
              rel:
                type: string
              href:
                type: string
              method:
                type: string
                enum: [GET, POST, PUT, DELETE, PATCH]

Ejemplo 2: Interfaz de Usuario Interactiva (Norma 9.9)​

La especificación OAS anterior se puede renderizar con herramientas como Swagger UI para proporcionar una interfaz donde los desarrolladores pueden:

  • Ver todos los endpoints y sus detalles.
  • Ver los schemas de los modelos.
  • Probar las llamadas a la API directamente desde el navegador (si está configurado).

🛠️ Herramientas y Consideraciones Adicionales (Contexto)​

  • Swagger Editor/UI/Codegen: Ecosistema popular para OAS.
  • ReDoc: Alternativa para generar documentación visualmente atractiva.
  • Stoplight: Plataforma de diseño y documentación de APIs.
  • Frameworks de API: Muchos frameworks (NestJS, Spring Boot, FastAPI) tienen integración para generar OAS desde el código.
  • Linters OAS: Herramientas como Spectral pueden usarse para validar y asegurar la calidad de la especificación OAS.