3가지 주요 API API

OJOCUIDAO: Lo escrito a continuaicón es simplemente mi opinión en base a mi experiencia. Si te parece que estoy diciendo una burrada te agradezco que me lo comentes

enums en lugar de valores booleanos를 사용합니다.

Imaginemos que trabajamos en una empresa de tarjetas. Imaginemos que estamos diseñando un endpoint GET/cards/id que te devuelve los datos de una tarjeta de crédito.

A grandes rasgos estos datos son el nombre del propietario, el número de tarjeta, la fecha de caducidad, el código de seguridad, el saldo y el estado de la tarjeta. (Activada 또는 Desactivada)

Con esta definición, mucha gente tenderá a Representative este concepto de la siguiente forma(El número de tarjeta se llama PAN):

{
      name: string,
      pan: number; 
      exp_year: number;
      exp_month: number;
      is_active: boolean; 
}

en principio, parece que tiene sentido pero Imaginemos que añadimos una nueva característica a nuestro sistema y ahora permitimos que una tarjeta pueda estar "inactiva, activa y también congelada"

🔥🔥🔥🔥🔥

El diseño anterior utiliza un valor booleano para el estado is_active por lo que para Representativear si está congelada tendríamos que añadir otro valor booleano is_frozen

{
      name: string,
      pan: number;
      exp_year: number;
      exp_month: number;
      is_active: boolean;
      is_frozen: boolean;
}

Esto nos deja con 4 가능한 조합:


활성
얼었다


아니요
아니요

아니요
예

예
아니요

예
예


lo malo es que desde el punto de vista del producto algunas de estas combinaciones pueden no tener sentido. Por ejemplo si esta congelada, da igual si esta activada o no.

y que pasa si queremos Representativear que está bloqueada por 사기?

{
      name: string,
      pan: number;
      exp_year: number;
      exp_month: number;
      is_active: boolean;
      is_frozen: boolean;
      is_blocked: boolean;
}

Poco a poco nuestro diseño se va complicando y empezamos a tener más y más combinaciones de valores booleanos.

Si alguien quiere hacer una aplicación y dibujar la tarjeta Representative ando el estado correcto tendrá que hacer una serie de comprobaciones en esos campos para conseguir la Representative adecuada.

Ahora veamos qué pasaría si utilizamos un enum (un string con una serie de valores posibles) para Representativear este estado:

{
    name: string,
    pan: number; // El número de tarjeta se llama PAN
    exp_year: number;
    exp_month: number;
    status: 'active' | 'inactive';
}

Después de añadir el requisito de poder congelar la tarjeta:

{
    name: string,
    pan: number; // El número de tarjeta se llama PAN
    exp_year: number;
    exp_month: number;
    status: 'active' | 'inactive' | 'frozen';
}

Después de añadir el requisito de bloquear tarjetas por 사기:

{
    name: string,
    pan: number; // El número de tarjeta se llama PAN
    exp_year: number;
    exp_month: number;
    status: 'active' | 'inactive' | 'frozen' | 'blocked';
}

Por esto creo que un enum es mucho más flexible que un campo booleano y al contrario de estos permite extender la API sin hacer 주요 변경 사항. Mi recomendación: Cada vez que vayas a Representative algo utilizando un boolean, reemplázalo con un enum con 2 valores. Lo agradecerás en el futuro.

Usa objetos en lugar de valores.

Otro consejo que se me ocurre dar es que las respuestas de una API deben ser diseñadas teniendo en cuenta futuros cambios.

Una forma sencilla de hacer nuestras APIs más resistance a cambios es utilizar objetos para Representativear conceptos.

Por ejemplo si junto a una tarjeta queremos devolver una lista con los identificadores de las últimas 5 transacciones mucha gente optará por un array de strings.

{
  name: string,
  pan: number; // El número de tarjeta se llama PAN
  exp_year: number;
  exp_month: number;
  status: 'active' | 'inactive' | 'frozen' | 'blocked';
  // Transaction contiene un array de IDs
  transactions: [ 
          '0000-0000',
          '0000-0001',
          '0000-0002',
  ]
}

Ahora Imaginemos que nos piden añadir el valor de cada transacción... No podemos hacerlo fácilmente sin romper el contrato de la API!

Sin embargo si desde el principio las transacciones fuesen objetos con un atributo ID

{
  name: string,
  pan: number; // El número de tarjeta se llama PAN
  exp_year: number;
  exp_month: number;
  status: 'active' | 'inactive' | 'frozen' | 'blocked';
  // Transaction contiene un array de IDs
  transactions: [ 
          {id: '0000-0000'},
          {id: '0000-0001'},
          {id: '0000-0002'},
  ]
}

Es trivial extenderlos con tantos campos como necesitemos:

transactions: [
  { id: "0000-0000", amount: 1000 },
  { id: "0000-0001", amount: 2000 },
  { id: "0000-0002", amount: 3000 },
];

Consulta Schema.org

La gente de Schema.org se ha preocupado de inspectigar y definir nombres estándar para Representativear conceptos en internet.

Por ejemplo para representar una Persona