Header Ads Widget

Ticker

6/recent/ticker-posts

Una toma pragmática de los anti-patrones de REST


 ¿Alguna vez has tenido esos momentos en los que te piden que hagas algo que se siente técnicamente mal? ¿Poner leche en la taza antes del té? (un problema muy británico sin duda). ¿Un bote de basura desbordado que USTED debe vaciar siempre? Todos tenemos nuestras cosas que nos molestan, es lo que nos hace humanos.

En la tecnología, estas cosas que nos molestan normalmente son muy grandes, y nos encanta hacer agujeros y cuestionar las decisiones de otras personas. ¿Usas ese marco? ¿Nombra sus variables con guiones bajos? De Verdad? Stack Overflow prospera con este tipo de cosas y no sorprende que en el mundo de las API sea ​​igual de exacerbado. ¿No haces hipermedia ? ¿Por qué hay un verbo en tu URI? ¿XML no JSON? Las opiniones son como las partes traseras proverbiales: todas las tenemos y las repartimos a voluntad.

Sin embargo, no hace falta decir que hay ocasiones en las que usted, un profesional de TI que ama su oficio, hará lo que crea que tiene más sentido a pesar de estas opiniones. O tal vez se encuentre en una situación en la que los requisitos comerciales requieran prácticas que no son exactamente las "mejores".

En esta publicación, analizamos algunos patrones y anti-patrones en el diseño de API y discutimos sus implicaciones en los seres humanos que tienen que implementarlos. Cubriremos cómo una actitud REST pragmática puede conservar la perspicacia técnica al tiempo que permite un margen para las necesidades comerciales.

¿Sin hipermedia? Eso no es DESCANSO

Hemos hablado de HATEOAS (hipermedia como motor del estado de la aplicación) en el blog de API nórdicas muchas veces antes. Técnicamente, en opinión del creador de REST y muchos otros, una API no es RESTful sin hipermedia . Si considera la mayoría de las API en este sentido, no incluir un enfoque HATEOAS en el diseño de su API es el mejor antipatrón de API de todos .

Independientemente de cuán “correcta” sea la implementación de HATEOAS en una API, existen pros y contras que el blog de las API nórdicas ha discutido en una publicación anterior . No cubriremos esto nuevamente aquí, aparte de hacer un comentario: a pesar de todas las cosas buenas que HATEOAS puede ofrecer a sus consumidores de API, implementarlo utilizando las herramientas disponibles para la mayoría de los diseñadores de API no es un paseo en el parque. Además, para los consumidores de su API, la implementación de HATEOAS puede en realidad diluir la simplicidad por la que se esfuerza como diseñador de API. El artículo de referencia expresa esto como tal:

“… La implementación es, por supuesto, completamente contextual a la situación en cuestión; para las API que no desean adoptar HATEOAS o hipermedia, la falta de adopción puede verse tanto como una característica como un inconveniente . En esas situaciones, especialmente en el caso de que no se implemente hipermedia, estas API no deben considerarse ni llamarse RESTful según las propias definiciones del creador ".

La lección clave aquí es que no tenga miedo de llamar a las cosas por su nombre real y esté preparado para describir correctamente sus intenciones de diseño. Una frase es “ REST pragmático , que significa una API que adopta la mayor parte de REST pero no todo. Esta frase ya no está de moda, pero muchas API todavía presentan las mismas características. Alternativamente, no hay herejía en la creación de una API de llamada a procedimiento remoto ( RPC ) si realmente describe lo que es Y es lo que quieren sus clientes .

Si no es DESCANSO, no lo llame así, pero no se enoje demasiado si de alguna manera dice en voz alta un diseño autoalamado “RESTful” que no es fiel a REST.

Leer más: Cómo mejorar la experiencia de la API con hipermedia

Un POST donde servirá un GET

Sin embargo, hay algunos casos en los que intenta abrazar la pureza técnica y encuentra resistencia interna. Desafortunadamente, como diseñador de API, es posible que no pueda hacer mucho al respecto.

Tomemos el caso de estudio de Dave the API Designer. Dave comenzó un nuevo trabajo en una empresa de servicios financieros, digamos un gran banco. Se vuelve loco usando todo su conocimiento de diseño para comenzar a esbozar una nueva API de consulta del cliente usando Swagger Editor y va muy bien. Al final del primer sprint, Dave lleva el diseño a mostrar y contar para discutir la especificación con sus compañeros y partes interesadas. La sesión va bien y todo el mundo apuesta por su diseño.

De repente, una flecha, directamente al corazón, disparada por alguien de seguridad de TI: “Dave, entiendo lo que estás haciendo con tu GET en el recurso del cliente, pero no hacemos eso aquí. ¿Puedes convertirlo en un POST? " La reacción instintiva de Dave es "qué diablos", pero se las arregla para suprimir esta respuesta y responder con un simple "por favor, explique?". Efectivamente, el equipo de seguridad explica:

Le dicen a Dave:

  • Tenemos muchos sistemas que se encuentran entre su API en API Gateway y la aplicación que expondrá la API en nuestra PaaS. Todos ellos están registrando solicitudes de alguna manera.
  • Una de las cosas que a menudo se registra es el URI.
  • Si el URI está registrado, puede contener parámetros de consulta que contengan datos confidenciales.
  • Esto aumenta la exposición de la organización a incumplir involuntariamente las regulaciones como los Estándares de seguridad de datos de la industria de tarjetas de pago que protegen la privacidad de dichos datos.
  • Sabemos que las plataformas de registro nunca registran la carga útil, por lo que los detalles confidenciales deben colocarse aquí.
  • Este es el estándar que hemos implementado y aprobado para este tipo de API. No estamos preparados para cambiar el estándar basado en el costo para reflejar la práctica de tala en todos nuestros sistemas.

La voz interna de la razón de Dave está gritando "¡¡¡NO !!!" y limpiar su escritorio de computadora portátil, pantalla y su colección de premios de Pop Funkos de Guardian. Sin embargo, el lado racional de él se ve obligado a aceptar la aprobación del diseño y no tiene argumentos razonables sobre cómo esto afectará la funcionalidad o la experiencia de los desarrolladores.

La lección aquí es: Todos queremos ser aficionados a REST y diseñar nuestras API al pie de la letra. Sin embargo, a veces eso va en contra de lo que es correcto para la organización para la que trabajamos. Como diseñadores de API, es posible que debamos hacer concesiones basadas en el contexto organizacional en lugar de las mejores prácticas . No es RESTful, pero hará el trabajo y hará felices a las partes interesadas.

Más sobre el diseño de API: 7 tendencias de diseño de API en crecimiento

Un POST idempotente

Cuando se habla de idempotencia (cuando una operación tendrá el mismo efecto ya sea que se ejecute una o varias veces), la mayoría de los diseñadores de API simplemente asumirán las reglas de HTTP según las instrucciones de Fielding. Parece bastante sencillo, ¿verdad?

Bueno, sí y no. Si bien las definiciones de los métodos en sí están consagradas en el estándar HTTP, los proveedores de API a menudo modifican las reglas para satisfacer sus necesidades. Por lo tanto, un POST idempotente se convierte en un concepto, especialmente en escenarios de API de pago. El proveedor de API quiere asegurarse de que si una llamada a la API para realizar un pago falla durante la ejecución, como en situaciones de tiempo de espera donde no se devuelve al cliente una respuesta HTTP discernible, los intentos posteriores no den como resultado el envío de una instrucción de pago duplicada. La idempotencia se logra solicitando al cliente que envíe exactamente la misma instrucción con un identificador que le indique al proveedor de API que podría haber visto esta instrucción antes.

La razón detrás de este enfoque de diseño es simple: los proveedores de API quieren asegurarse de que los consumidores de API no dupliquen los pagos, basándose en que esto tiene un efecto en personas reales, es decir, los consumidores de API valoran a los clientes . Hay varios ejemplos de este enfoque, en particular PayPal y la API de inicio de pago de banca abierta del Reino Unido .

Un POST idempotente, si bien no es RESTful debido al hecho de que ignora las reglas de HTTP, aporta mucho valor al consumidor de API al ayudarlo a brindar una excelente experiencia de pago a sus clientes. En casos como este diseño pragmático y determinista de la API como producto , defender al consumidor de la API de enviar por error múltiples instrucciones de pago, tiene prioridad sobre la "corrección" técnica para muchos proveedores de API.

¿Un consumidor? Bueno, deberían ser una entidad

Muchos diseñadores que establecen sus especificaciones de API por primera vez tienen la tendencia a tomar la idea de entidades como adoptada por REST y convertir todo en una entidad gobernada por una API . Esto incluye al consumidor de API que llama a la API, que es un enfoque que conduce a una especificación que incorpora URI como esta:

GET /consumer/{consumerId}/customers/{customerId}

Para el diseñador, esto podría tener mucho sentido. Sin embargo, hay muchas razones por las que este tipo de construcción no es una buena práctica:

  • Es importante solo para el proveedor de API, no para el consumidor: el consumidor (en general) solo estará interesado en sí mismo y en nadie más. Esto da como resultado una mayor complejidad en el URI que ofrece un valor cero para el consumidor.
  • El diseñador está mezclando el modelo de seguridad y el modelo de datos al requerir que un consumidor se identifique "a sí mismo" en el URI. Esto conduce a una interfaz que es más frágil y también sujeta a posibles abusos, es decir, si hay un problema con el modelo de seguridad que envuelve la API, un malhechor puede dirigirse a otros clientes una vez que hayan pasado los controles de seguridad. Si bien este estilo de API se está volviendo menos común para las empresas de API primero, las organizaciones que miran más hacia adentro aún consideran esta opción de diseño.
  • Introduce algo de maldad en torno a los recursos de anidación, especialmente en vista de una estrategia de control de versiones. Como señala Zdenek Nemec , este enfoque, que él define como la "falacia de los recursos anidados" , puede conducir a una interfaz compleja que los desarrolladores encontrarán difícil de comprender.

El punto clave aquí es: Modele lo que necesita modelar en sus API, no otras cosas que puedan estar asociadas . Si hay una necesidad de relacionar abiertamente una entidad con otra, asegúrese de usar el enfoque HATEOAS (o incluso considere GraphQL …) en lugar de usar la construcción frágil de los recursos de anidación. Hará que su API sea más limpia y más fácil de entender.

Cómo mantenerse cuerdo con un descanso pragmático

Seamos realistas: algunas partes de esta publicación lo harán asentir con sagacidad, estar de acuerdo con los puntos señalados o rechinar los dientes y estar listo para hacer un agujero en la pizarra más cercana. Hay un montón de otras cosas, como las versiones en el URI, por ejemplo, en las que podríamos entrar y que serían igualmente divisivas.

Sin embargo, en este mundo todavía en proceso de formulación de cómo se ve un buen diseño de API, todos podríamos aprender algo si documentamos nuestras decisiones de diseño, para que todos puedan ver por qué implementamos una solución de esa manera, y investigamos y observamos lo que sucedió antes.

Por encima de todo, nosotros, como técnicos, debemos aprender a relajarnos . Vendrán requisitos y personas que nos obligarán a implementar un patrón o antipatrón que no nos gusta. Por lo tanto, el sentido de la perspectiva puede ser un activo muy útil, así que trate de recordar, todo es solo unos y ceros.

Publicar un comentario

0 Comentarios