Header Ads Widget

Ticker

6/recent/ticker-posts

7 organismos de normas API con los que participar

Kenia diciembre 10, 2020

 

Es posible que esté familiarizado con las especificaciones de API como OpenAPI o AsyncAPI, pero ¿quiénes son los grupos que mantienen estos estándares? ¿Y cómo puede participar en estas comunidades para ayudar a dar forma a la revolución de las API?

Estos son los principales cuerpos estándar que moldean la industria API tal como la conocemos. Estas iniciativas, grupos de trabajo y proyectos colaborativos están estandarizando activamente las especificaciones, formatos y esquemas que aportan interoperabilidad al mundo de las API.

Para las empresas de tecnología, tener presencia en los grupos de estándares es imprescindible. Para las organizaciones relacionadas con API, no es diferente. Contribuir a estos proyectos podría ayudar a los desarrolladores individuales o las empresas a establecer activamente los estándares de integración de su sector. Afortunadamente, estas iniciativas de código abierto dan la bienvenida a los colaboradores.

Por supuesto, las políticas de contribución varían de uno a otro. Entonces, revisé cada grupo e intenté darle sentido a sus procesos. He incluido formas de participar, como pautas de contribución, enlaces para realizar solicitudes de extracción públicas e información de membresía.

Este artículo se inspiró en la vibrante discusión de la comunidad y los organismos de estándares emergentes presentes en la Conferencia de Especificaciones API 2020 . ¡Gracias a The Linux Foundation por hospedar!

1. Iniciativa OpenAPI

La Iniciativa OpenAPI (OAI), respaldada por la Fundación Linux, es una comunidad de código abierto que crea metadatos independientes del proveedor para las API RESTful. Anteriormente conocido como Swagger, OpenAPI Specification (OAS) ha surgido como el formato de facto para describir las API web. OAS se describe aquí en Github .

El Comité Directivo Técnico (TSC) de OpenAPI dirige el desarrollo de la Especificación OpenAPI (OEA). El TSC considera los comentarios de la comunidad, los problemas abiertos y las solicitudes de extracción al actualizar la especificación. Lorna Mitchell de Vonage, y colaboradora temprana de OpenAPI, describe OpenAPI como un "proceso abierto" donde "los parches son generalmente bienvenidos".

En última instancia, la OAI tiene un escalón burocrático de gobierno de la OEA, con una Junta de Gobierno, una Junta de Supervisión Técnica y un Comité Directivo Técnico, y múltiples grupos de trabajo. No espere un proceso sencillo al realizar solicitudes de cambios importantes. La Carta del Proyecto describe el proceso de la Iniciativa OpenAPI y las prácticas de membresía. A continuación se muestran algunas formas de participar:

2. GraphQL Foundation

GraphQL, el lenguaje de consulta de datos y la especificación, se desarrolló inicialmente en Facebook. Ahora, es de código abierto públicamente, alojado bajo la Fundación Linux, y la comunidad dicta en gran medida su futuro.

GraphQL opera GraphQL Working Group , una reunión mensual de mantenedores de herramientas y bibliotecas GraphQL, abierta a los miembros. Debe solicitar convertirse en miembro: solicitud de membresía aquí . GraphQL Foundation ofrece una membresía de especificación corporativa, buena para empresas, y una membresía individual para desarrolladores o estudiantes individuales.

GraphQL en sí está abierto para solicitudes de extracción públicas y los editores de especificaciones a menudo combinan correcciones, mejoras o pequeños errores. Sin embargo, los cambios más importantes los dicta el grupo de trabajo. A continuación se muestran algunas formas de participar:

3. Iniciativa AsyncAPI

¿Sabía que los primeros patrocinadores de la Iniciativa AsyncAPI se anunciaron en la Cumbre de la Plataforma de APIs nórdicas en 2018 ? Las API nórdicas han compartido los pensamientos del fundador de AsyncAPI, Fran Méndez, sobre la mensajería asincrónica en publicaciones de blogs y charlas durante años, y he sido un defensor de AsyncAPI desde su debut.

AsyncAPI es como OpenAPI, pero para protocolos asincrónicos como MQTT. La especificación AsyncAPI está diseñada para describir situaciones de IoT, mensajería e impulsadas por eventos en las que la comunicación no es síncrona. Desde su debut como un nuevo estándar de definición de API, AsyncAPI ha sido moldeado en gran medida por las aportaciones de la comunidad. Fran Méndez y Łukasz Górnicki mantienen activamente AsyncAPI. El proyecto da la bienvenida a los colaboradores en Github .

AsyncAPI ofrece un campo de juego para generar documentación y validar las especificaciones de AsyncAPI, y la comunidad circundante ha creado muchas herramientas, desde generadores de documentos, validadores, entornos simulados y más. A continuación se muestran algunas formas de participar:

4. Bloques de creación para las API de HTTP - Grupo de trabajo IETF

IETF es bien conocido como el organismo estándar que mantiene y desarrolla las especificaciones básicas para HTTP. Los miembros de IETF ahora han esbozado una nueva carta para el Grupo de Trabajo de Bloques de Construcción para API de HTTP .

HTTP no solo es estándar para la web, sino también ubicuo para la comunicación máquina-máquina. Dado que la mayoría de las API web utilizan HTTP como protocolo de comunicación estándar, las "API HTTP" se han convertido en un término general para describir dichos servicios.

El Grupo de Trabajo de Bloques de Construcción para APIs HTTP propuesto (httpapi) tiene la intención de desarrollar nuevos encabezados HTTP y capacidades para soportar necesidades de API HTTP matizadas. Por ejemplo, se podría establecer un estándar de paginación universal para las API HTTP. La firma de mensajes HTTP o un campo de encabezado de límite de velocidad son borradores potenciales que podrían reforzar los estándares de la API HTTP.

“Los buenos protocolos son definidos por una amplia comunidad abiertamente”, dijo Mark Nottingham de IETF en una resentida charla de ASC. De acuerdo con la carta, se agregarán nuevos elementos de trabajo después de una Convocatoria de adopción en la lista de correo del grupo de trabajo y la aprobación del director del GT. El grupo es todavía bastante nuevo, pero aquí hay algunas formas de participar:

5. Grupo de interés W3C Web of Things

Las empresas de tecnología que trabajan con dispositivos de Internet de las cosas (IoT) pueden encontrar el Grupo de interés de la Web de las cosas especialmente interesante. Este grupo de interés del W3C proporciona un foro público para acelerar los estándares web para dispositivos IoT.

El grupo de trabajo W3C Web of Things (WoT) está estandarizando una descripción de cosas (TD), un formato de descripción de API para dispositivos IoT. Con las descripciones estándar de IoT, los desarrolladores podrían combinar geniales mashups de IoT y flujos de dispositivo a dispositivo.

En un "nivel de cosa", la descripción de cosa de Web of Things (WoT) incluye anotaciones semánticas, metadatos de cosa, seguridad, definiciones de interacción y enlaces a otros documentos. El grupo de trabajo también admite un área de juegos para la validación, plantillas de enlace, una API de secuencias de comandos para la comunicación independiente del protocolo y otras herramientas.

WoT parece estar gobernado por empresas con pies en hardware y software, como Intel y Siemens. Para participar, realizan una llamada semanal los miércoles para el grupo y los invitados. Cada grupo de trabajo tiene sus propias llamadas semanales, donde el público está abierto a hacer preguntas. A continuación se muestran algunas formas de participar:

6. gRPC

Aunque es menos un proyecto estándar y más de código abierto, gRPC ha experimentado una rápida adopción en el espacio de la API. gRPC formaliza un proceso para la comunicación de servidor a cliente, utilizando stubs de cliente que interactúan con los recursos del servidor. gRPC nació de la única infraestructura RPC de uso general de Google llamada Stubby. En 2015, lanzó una actualización de código abierto de la herramienta con mucha fanfarria: gRPC ahora impulsa muchos microservicios y la "última milla" de la informática (móvil, web e IoT). A continuación se muestran algunas formas de participar:

7. Esquema JSON

JSON Schema es un vocabulario que le permite anotar y validar documentos JSON, dice json-schema.org . JSON, una herramienta independiente del lenguaje y la plataforma, describe un conjunto de restricciones para la interacción entre documentos JSON. Dado que JSON es un formato de datos de API REST común, JSON Schema ha ido creciendo en uso e importancia.

Menciones honoríficas

En esta publicación, me centré principalmente en los organismos de estándares en torno a las especificaciones de API, pero ciertamente hay otros formatos de descripción y protocolos relacionados con las API con sus propios grupos. Otros incluyen:

  • OData : un protocolo abierto estandarizado por OASIS. Permite la creación y consumo de APIs RESTful consultables e interoperables de forma estándar.
  • ALPS por Mike Amundsen.
  • Estándares de identidad involucrados en la seguridad de API: OAuth 2.0 , OpenID Connect , SCIM .
  • FHIR Core Work Group : Fast Healthcare Interoperability Resources (FHIR) es un estándar definido por HL7 para registros médicos.
  • Hydra es un marco para desarrollar API web impulsadas por hipermedia.
¿Dejé de lado una iniciativa importante de la industria de API? Comente a continuación y consideraré agregarlo a la lista anterior.

Los organismos estándar necesitan diversidad

Puede parecer una guerra de especificaciones nuevamente, pero en realidad, muchos de estos grupos de estándares abiertos se complementan entre sí o apoyan industrias únicas en lo que respecta a estilos específicos.

La participación en comunidades de código abierto ayuda a hacer avanzar sus proyectos. Ya sea para corregir un error o solicitar una nueva función, el voluntariado activo para mejorar estos estándares puede fortalecer la economía en general. También es crucial que las herramientas auxiliares que consumen estas especificaciones estén al tanto de su evolución.

Los organismos estándar en la industria de las API suelen estar bastante abiertos a aportar nuevas perspectivas para ayudar a guiar el impulso. Es esta diversidad la que puede garantizar que las especificaciones cumplan con la mayoría de los casos de uso y también consideren escenarios marginales. Por ejemplo, OpenAPI Initiative está animando a verticales únicas a compartir su perspectiva. Ahora hay un grupo de trabajo de OpenAPI con temas de viajes para ayudar a OpenAPI a evolucionar con la industria de viajes.

Tenga en cuenta; ¡no siempre es un proceso fácil! La realidad es que las carrocerías estándar pueden ser bastante lentas. “Cada funcionalidad agregada hace que una especificación sea más complicada”, recordó Darrell Miller de ASC. La razón por la que existen procesos de estandarización complejos es que deben abarcar cambios que funcionen bien dentro de toda una industria. Una posible desventaja de los estándares es el mínimo efecto de denominador común.

Reflexión final: Contribuir

La creación de métodos estandarizados para describir las API es vital para promover la interoperabilidad de la industria. Las políticas de contribución abiertas ayudan a que las especificaciones sean compatibles con las pilas actuales o antiguas y las preparan para el futuro para que evolucionen en nuevas direcciones.

Los formatos estándar también pueden habilitar herramientas interesantes para la generación de documentación, las API de espacio aislado y el descubrimiento, al tiempo que permiten integraciones de socios más fáciles. Sin mencionar que tener una especificación como fuente de verdad puede guiar los enfoques de diseño primero y agilizar el estilo de toda la empresa.

Todos los proyectos anteriores tienen distintas políticas. Algunos son de naturaleza más de código abierto; algunos son específicos del sector o pueden no ser tan inclusivos; algunos aceptan contribuciones financieras para un puesto en la junta directiva, etc. En general, sin embargo, todos agradecen las nuevas contribuciones e ideas.

Ya sea que sea un contribuyente, un mantenedor o un desarrollador de implementación, ser parte del ecosistema es importante. Como mínimo, ver temas o debates abiertos de Github puede ayudarte a opinar sobre los estándares emergentes. Porque, sin una voz en la creación de estándares API, es posible que no tenga voz en la economía de las API.

Publicar un comentario

0 Comentarios

Dejanos tu comentario para seguir mejorando!