Description
Cualquiera puede hacer que un endpoint devuelva JSON. Diseñar una API que otros ingenieros puedan usar sin preguntarte qué hace, que sobreviva a un cambio sin romper a todos los clientes, y que aguante carga real y atacantes reales, es otra habilidad. La mayoría de las APIs REST son una pila de endpoints que cada uno tuvo sentido solo y se contradicen juntos: nombres inconsistentes, status codes que mienten, errores que un cliente no puede parsear, sin paginación hasta que la lista tiene diez mil filas, la autenticación pegada al final, y un cambio que rompe todo y sale sin versión. El HTTP y el JSON son la parte fácil. El diseño, la consistencia y el contrato que estás firmando son la parte que decide si tu API es un placer o una carga.
Este libro te enseña a diseñar APIs REST como un contrato del que otros ingenieros dependen, no como una pila de endpoints que cada uno tuvo sentido local. Arranca desde REST como modelo (recursos, no acciones, y lo que eso te da) y construye el criterio de diseño que hace una API predecible: modelar recursos y sus relaciones, usar los métodos HTTP y los status codes por lo que de verdad significan, nombrar y estructurar las URLs para que un desarrollador pueda adivinar el próximo endpoint, y devolver errores que un cliente de verdad pueda manejar. Después cubre las partes que separan un juguete de una API de producción: paginación, filtrado y orden que no se caen con una colección grande, validar la entrada y nunca confiar en el cliente, autenticación y autorización bien hechas (tokens, scopes, y no filtrar datos entre usuarios), idempotencia para que un request reintentado no cobre dos veces, y rate limiting y caché para que la API siga en pie. Los capítulos más difíciles son sobre el contrato en el tiempo: versionar sin romper a todos los clientes, evolucionar una API agregando en vez de cambiando, documentarla para que la gente no tenga que leer tu código, y la disciplina de que un endpoint público es una promesa que tenés que cumplir. Los ejemplos son una API real, mostrada diseñada mal y después bien. Para ingenieros backend que quieren construir una API que otros estén contentos de usar y que no tengan que reescribir en un año.
Para quién es este libro
Este libro es para: ingenieros backend que saben hacer que un endpoint devuelva JSON y ahora tienen que diseñar una API que otros equipos usan, versionar sin romper, y mantener rápida y segura bajo tráfico real.
El atajo que nadie te regala
Los 4 pasos para volverte el ingeniero del que dependen los demás equipos. El método para diseñar una API REST que otros ingenieros tratan como un contrato en el que confían, no como una pila de endpoints que tienen que sacar por ingeniería inversa. La construís en capas que sostienen, así un desarrollador puede adivinar tu próximo endpoint sin leerte la mente, aguanta tráfico real y atacantes reales, y podés cambiarla durante años sin romper un solo cliente. Pasás de una pared de endpoints en la que nadie coincide a una API que un socio integra en una sola tarde.
- Modelá de qué está hecha la API
- Hacé la superficie predecible de adivinar
- Endurecela para tráfico real y atacantes
- Cambiala durante años sin romper clientes
Con qué te vas a quedar
- Capítulo 1: La ingeniera que no sabía a cuál de tus endpoints creerle
- Capítulo 2: Cuarenta endpoints y ningún cliente coincide en cuál llamar
- Capítulo 3: Si errás los sustantivos, vas a pedir disculpas en la documentación todo un año
- Capítulo 4: El 200 OK que dejó el spinner girando para siempre
- Capítulo 5: URLs que un desarrollador puede adivinar sin abrir tu documentación
- Capítulo 6: La mitad de usar tu API es el momento en que dice que no
- Capítulo 7: En verde en cada test, caído con un millón de filas
- Capítulo 8: El usuario que se hizo admin con un solo campo de más
- Capítulo 9: Cambiá un dígito en la URL y leé los datos de otra empresa
- Capítulo 10: Asumí que cada request va a llegar dos veces
- Capítulo 11: Cambiar un contrato mientras la gente está parada encima
- Capítulo 12: Tu API funciona, pero nadie encuentra cómo usarla
- Capítulo 13: La API que un socio integra en una sola tarde
