Sobre el diseño de las APIs de Slack
Ya hace muchos años que descubrimos las APIs abiertas (por ejemplo, en Flickr) y las posibilidades que ofrecían. Sin embargo (igual es mi impresión) en los últimos años se está hablando más, y hay quién lo hace mejor y quién lo hace peor.
Recordemos aquí que un API es un mecanismo para desarrollar programas con los servicios de alguien: nos proporciona una forma de llamar a sus ‘primitivas’ básicas y, en consecuencia, hacer programas para nuestro uso (y el de otros) con las herramientas de su plataforma.
Slack es uno de esos casos donde permiten la creación de bots y diversos autoamtismos sobre su plataforma y en How We Design Our APIs at Slack hablan del diseño de sus APIs.
La motivación tiene con que sean cómodas de usar, los desarrolladores tengan ganas de hacerlo y generen proyectos interesantes.
If APIs are designed well, developers will love them, and can become the most creative innovators using your APIs. They will invest heavily, and sometimes even become evangelists for your APIs. We also value a developer’s time and the resource they risk by building on our platform. Bad API design leads to a bare minimum adoption, and even frustration. Bad APIs become a liability for a company.
Y luego nos dan sus principios:
Hacer una cosa y hacerla bien.
- Do one thing and do it well
Hacer fácil y rápido el comienzo.
- Make it fast and easy to get started
Preouparse de la consistencia intuitiva.
- Strive for intuitive consistency
Devolver errores con significado.
- Return meaningful errors
Diseñar para el crecimiento y las prestaciones.
- Design for scale and performance
Evitar cambios disruptivos (que rompan cosas)
- Avoid breaking changes
Luego hablan del proceso de diseño, en cuatro pasos: escribir una especificación, revisarla internamente, recibir realimentación de los primeros colaboradores y tener una fase de pruebas
- Write an API spec
- Internal API review
- Early partner feedback
- Beta testing
Interesante.