¿Cómo crear una API para mi complemento?

La API que ofrece en un complemento o un tema depende de la lógica de ese código específico. Probablemente no haya una guía que se aplique a todas las situaciones.

Soy colaborador de varios complementos con API, y lo que he aprendido hasta ahora es:

1. No ofrezca una API hasta que realmente sepa cómo las personas usan su código.

   Suelte las primeras dos o tres versiones sin ninguna API. No hay acciones ni filtros personalizados, ni métodos ni funciones públicas (y nunca variables globales) si es posible. Espere las solicitudes de sus usuarios, pero no agregue el código hasta que sepa que su estructura de código interno funcionará a largo plazo.

   Mantener la compatibilidad con versiones anteriores de una API es difícil . Podría evitar mejoras necesarias en otros lugares. Piense en todas las variables globales que WordPress no puede eliminar en la actualidad. Esa es una mala API, y estamos atascados con ella durante muchos años, porque la gente ya la usa .

2. Considere la posibilidad de separar su API del resto del código (consulte el enlace anterior para obtener una idea).
   Su API debería ser útil no solo para desarrolladores externos, sino también para usted. No agregue restricciones para usted mismo si no tiene que hacerlo.

3. Coma su propia comida para perros.
   Si ofrece ganchos personalizados, utilícelos en su código. Esto le dará a otros desarrolladores ejemplos útiles, y puede ver las posibles fallas pronto.
   Si el núcleo de WordPress usara internamente la llamada API de configuración , no tendríamos este lío hoy. Tal vez.

4. Predicar con el ejemplo.
   Use las partes buenas de la API principal de WordPress en su complemento. Evite objetos anónimos , constantes, variables globales y cualquier tipo de código impredecible .

5. Asegúrese de estar usando un esquema de nombres consistente (no de un desastre ), y coloque todo bajo tu propio espacio de nombres.

6. Escribe la documentación primero. Suelte una nueva (parte de una) API más adelante.
   Crea ejemplos útiles para todo. Se sorprenderá al ver cuántos agujeros y redundancias encontrará.

7. Evita el infierno de devolución de llamada.
   Ofrezca herramientas específicas para depurar su API cuando las cosas no funcionen como deberían (incluyendo los scripts y las hojas de estilo no minificados). He escrito un ejemplo de cómo depurar AJAX , solo para ilustrar lo creativo que puedes ser aquí. Nuevamente, estas herramientas deben explicarse en su documentación antes de lanzarlas.

8. Una alternativa al paradigma de devolución de llamada de WordPress podría ser el patrón de observador . Esto levantaría la barrera para los desarrolladores externos, pero podría resultar en un mejor código en ambos lados.