Cómo ser compatible con API¿Qué es API? El nombre completo de API es Interfaz de programación de aplicaciones. Muchas veces, los desarrolladores de programas solo usan funciones e interfaces de clases como parte de la API, mientras ignoran otras interfaces de programación importantes. De hecho, las API comunes en la programación front-end de Javscript incluyen: funciones, interfaces de clases, incluidos parámetros, valores de retorno, operaciones específicas desde funciones a objetos externos (generalmente DOM), etc. Protocolos de interfaz de red, como JSON, formatos de datos XML para interactuar con el backend, o nombres de funciones, estilos en devoluciones de llamadas de script y dependencias externas de la interfaz HTML (dependencia de funciones específicas del navegador) Dependencias externas (dependencia de funciones específicas del navegador) Algunas implementaciones internas filtradas inadvertidamente se volverán más oscuras y difíciles de entender a medida que lleguen a una etapa posterior, y es menos probable que se tomen en serio una vez que estas API cambien, es posible que la persona que llama no cumpla con las expectativas del programa, o incluso. el programa informará directamente un error. ¿Por qué no se puede cambiar la API? Los usuarios de API esperan que los proveedores de API proporcionen funcionalidades e interfaces claras para sus programas. Más importante aún, los usuarios quieren poder actualizar el código de terceros "sin pensar" cuando se actualiza el programa. Realizar cambios en cualquiera de las 5 API anteriores sería costoso y requeriría que el usuario solucione los problemas de todas las llamadas, cambie ciertos protocolos y realice ajustes en todas las partes relevantes del programa, todo lo cual sería difícil para el usuario. Es un trabajo adicional inesperado. . Si después de todo este arduo trabajo se descubre un error durante las pruebas, el usuario se verá aún más afectado. Si la interfaz de la aplicación cambia con frecuencia, los usuarios perderán la confianza en el programa y estarán más dispuestos a obtener el código fuente y modificarlo según sus necesidades. Es más aceptable mantener su propia API interna que llamar a una API externa en constante cambio, aunque esto anula por completo el propósito del desarrollo modular y colaborativo. Finalmente, ¿por qué necesitamos modificar la API? ¿Para que la API se vea más bonita? ¿Para proporcionar características más interesantes? ¿O es simplemente porque sentimos que es hora de un cambio? Los promotores de proyectos son pragmáticos en este tema. Pero eso no significa que ya no mejoraremos la API. Antes de hablar formalmente sobre compatibilidad, primero debemos descubrir qué es una buena API, porque la causa raíz de la incompatibilidad de API siempre proviene de la idea de "esperar que la API mejore a través de este cambio". Fácil de entender Si la mayoría de los usuarios no pueden aprender rápidamente una API, entonces no debe ser una buena API. Por ejemplo, las personas mayores y los niños pueden aprender el desbloqueo deslizante de iOS en poco tiempo, y el clásico desbloqueo de dos botones de Nokia, ya sabes. Coherencia La coherencia puede reducir en gran medida los costos de aprendizaje y uso de los usuarios, y los esfuerzos de aprendizaje anteriores de los usuarios seguirán siendo recompensados. Las API que son fáciles de encontrar y aprender deben documentarse y presentarse claramente, con tantos ejemplos y códigos de copiar y pegar como sea posible para reducir la barrera para los usuarios. Proporcionar soluciones simples La API debería poder resolver problemas complejos y proporcionar muchos elementos configurables, pero para las situaciones más comunes, si hay una solución simple para que la usen los usuarios, esto puede mejorar en gran medida la usabilidad de la API y proteger a los usuarios existentes. trabajo en la API El trabajo anterior de los usuarios se desarrolló basándose en llamar a la API. Por lo tanto, si bien aportan valor a los usuarios, los resultados de su trabajo anterior no se pueden destruir. Esto puede aportar valor a los usuarios sin destruir los resultados del trabajo de los usuarios. Cómo garantizar la compatibilidad de API Utilice un buen pensamiento de diseño durante el proceso de diseño. Si puede diseñar de las siguientes maneras, la vida útil de la API será más larga. Utilice un diseño orientado a casos, recopile sugerencias de los usuarios y simule usted mismo como usuario. Asegúrese de que el diseño de la API sea fácil de usar y garantice razonablemente que los requisitos posteriores se puedan cumplir en forma de extensiones. Cuanto menos contenido tenga la primera versión, mejor, porque los nuevos requisitos se pueden cumplir en forma de extensiones, por lo que menos. mejor. Dado que se pueden cumplir nuevos requisitos en forma de extensiones, hacer lo menos posible es una solución eficaz para frenar los errores de diseño de API. Proporcionar especificaciones claras de API y documentación al público para evitar que los usuarios utilicen la API incorrectamente, especialmente para evitar que los usuarios conozcan y utilicen indebidamente la API detrás de la API (consulte la Sección 1). Además, a continuación se enumeran algunos métodos de diseño específicos: los métodos son mejores que los atributos y los métodos de fábrica son mejores que los constructores.
Evite la herencia excesiva. Evite optimizar o reutilizar el código debido al impacto de la API. Los parámetros de extensión de programación orientados a la interfaz deben facilitar el posicionamiento razonable de los componentes y determinar cuántas interfaces están expuestas. Después de completar el diseño de la API, se debe realizar una revisión efectiva de la API. someterse a una revisión integral del diseño. Los puntos clave son los siguientes: Se deben proporcionar casos de uso integrales y basados en casos de uso antes de la revisión para garantizar la racionalidad e integridad de los casos de uso. Integridad. Consistencia, si es consistente con el estilo de interfaz de otros módulos del sistema y si se ajusta al diseño de interfaces simétricas. Simple y clara, la API debe ser fácil de entender, aprender y usar, y no debe usarse mal fácilmente y causarnos más problemas. La API debe ser lo más pequeña posible. Si una API se puede hacer pública o no, no la haga pública. No es demasiado tarde para convertirla en una interfaz pública cuando los usuarios realmente la necesitan. Apoye la mejora continua, ya sea que la API se pueda ampliar fácilmente para agregar funcionalidad y optimizarla. Comprender el ciclo de vida de las API. Cada API tiene un ciclo de vida. Debemos alargar el ciclo de vida de la API y permitir que la API muera sin problemas al final del ciclo de vida. Informar a los usuarios sobre cómo diseñamos la API, evitar el uso indebido y brindar orientación. El uso indebido suele ser un factor importante para acortar la vida útil de la API. La API no será estable al principio. Las API tienen mayor vitalidad. Mejorar la clasificación de la API: Uso interno; Desarrollo o prueba; Abandonar la API. Para evitar el uso indebido de la API, podemos ajustar el nivel de la API. El nivel de una API se puede ajustar para ampliar su impacto y finalizar el ciclo de vida de la API de manera más elegante. En el pasado, siempre quisimos revertir los diseños "malos" y rediseñar las API de acuerdo con las "buenas" ideas, pero después de un tiempo, nos encontrábamos con la misma situación nuevamente y necesitábamos revertirla nuevamente. Pero después de un tiempo, volverás a encontrarte con la misma situación y necesitarás cubrirla nuevamente. Si no tenemos un enfoque eficaz para la mejora incremental, confiar en revertir el diseño existente y rediseñar la API simplemente nos devolverá al punto de partida, repitiendo el mismo proceso. Es importante tener un método eficaz de mejora continua para mejorar la API y mejorarla sin dejar de ser compatible con la API. Las interfaces de las aplicaciones deben ser comprobables y las pruebas no deben depender de la implementación. Las API bien probadas, especialmente aquellas que se han sometido a rigurosas "pruebas de integración de compatibilidad" (ver más abajo), tienen más probabilidades de actualizarse sin problemas de compatibilidad. Las pruebas de integración de compatibilidad se refieren a un conjunto de casos de prueba que colocan la API en el lugar del usuario. Después de actualizar la API, los casos de prueba se prueban para ver si pasa la prueba exactamente como se esperaba y para encontrar tantos problemas de compatibilidad como sea posible. Evite vistas extremas Al diseñar interfaces de aplicaciones, es importante evitar vistas extremas, especialmente las siguientes: Debe ser hermosa (¿La API tiene que ser hermosa?) Como se mencionó anteriormente) La API debe usarse correctamente (es difícil para los usuarios Para entender cómo usar la API correctamente, los diseñadores de API deben considerar completamente el mal uso de la API: si una API se puede usar mal, entonces definitivamente se usará mal) Debe ser simple (siempre enfrentaremos requisitos complejos, podemos hacer ambas cosas al mismo tiempo). tiempo Una mejor API es una mejor API) Debe ser de alto rendimiento (el rendimiento se puede optimizar de otras maneras y no debería afectar el diseño de la API) Debe ser absolutamente compatible (aunque este artículo ha mencionado cómo garantizar la compatibilidad, todavía necesitamos para darse cuenta de que se pueden tolerar muy pocas incompatibilidades) Algunas implementaciones específicas de una API inevitablemente morirán o cambiarán. Debemos aceptar y enfrentar este hecho. A continuación se enumeran varias condiciones para garantizar la compatibilidad de la API. , no podremos utilizar la API, pero debemos asegurar la compatibilidad de la API. A continuación se muestran algunas formas de adaptar su API para garantizar la compatibilidad: Marque la API como obsoleta y reconstrúyala como una nueva API. Esta es la única manera de hacerlo si la desaparición de su API es inevitable. Agregue parámetros adicionales u opciones de parámetros para lograr adiciones de funciones. Divida la API existente en dos partes para proporcionar una API principal optimizada que la encapsule para implementar funciones que se implementaron en la API principal en el pasado. Normalmente, esto se utiliza para resolver situaciones en las que un usuario necesita una versión condensada del código.