https://takao.blog/es/tags/api/Recent content in Api on Commentary of TakaoHugo -- gohugo.ioesCommentary of TakaoSun, 12 Jul 2026 04:12:51 +0900https://takao.blog/es/web/web-api-design-rest-best-practices/Fri, 25 Apr 2025 00:00:00 +0900https://takao.blog/es/web/web-api-design-rest-best-practices/<img src="https://takao.blog/img/thumbnail/web-api-design-rest-best-practices-es.png" alt="Featured image of post Diseño de APIs REST: Mejores prácticas" /><p>Una API REST bien diseñada es intuitiva, consistente y fácil de mantener. Estas prácticas aplican a cualquier lenguaje y framework.</p> <h2 id="nombres-de-recursos">Nombres de recursos </h2><p>Sustantivos en plural: <code>/users</code>, <code>/articles</code>. Jerarquía: <code>/users/123/posts</code>. URLs limpias, sin verbos. Versionado: <code>/v1/users</code>.</p> <h2 id="métodos-http">Métodos HTTP </h2><p>GET (leer), POST (crear), PUT (reemplazar), PATCH (actualizar parcial), DELETE (eliminar). Siempre respeta la semántica HTTP.</p> <h2 id="respuestas-consistentes">Respuestas consistentes </h2><p>Estructura JSON unificada. Códigos HTTP correctos: 200, 201, 204, 400, 401, 403, 404, 409, 422, 500. Mensajes de error descriptivos.</p>https://takao.blog/es/web/graphql-vs-rest-2024/Tue, 03 Dec 2024 00:00:00 +0900https://takao.blog/es/web/graphql-vs-rest-2024/<img src="https://takao.blog/img/thumbnail/graphql-vs-rest-2024-es.png" alt="Featured image of post GraphQL vs REST en 2024: Cuál elegir" /><p>REST y GraphQL son enfoques diferentes para diseñar APIs. La elección depende del caso de uso, no de la moda.</p> <h2 id="rest">REST </h2><p>Recursos como URLs. Métodos HTTP (GET, POST, PUT, DELETE). Cacheable por naturaleza. Familiar y probado. Overfetching y underfetching son desventajas.</p> <h2 id="graphql">GraphQL </h2><p>Un solo endpoint. El cliente solicita exactamente los campos que necesita. Tipado fuerte (schema). Resolvers. Suscripciones para tiempo real.</p> <h2 id="ventajas-de-graphql">Ventajas de GraphQL </h2><p>Sin over/under fetching. Documentación interactiva (GraphiQL). Tipos fuertes. Ideal para dashboards y apps con datos complejos.</p>https://takao.blog/es/web/api-rate-limiting/Tue, 07 May 2024 00:00:00 +0900https://takao.blog/es/web/api-rate-limiting/<img src="https://takao.blog/img/thumbnail/api-rate-limiting-es.png" alt="Featured image of post Rate Limiting en APIs: Estrategias y mejores prácticas" /><p>Rate limiting protege las APIs contra abusos limitando el número de solicitudes en un período de tiempo. Esencial para seguridad y estabilidad.</p> <h2 id="estrategias-comunes">Estrategias comunes </h2><p>Fixed Window: cuenta en ventanas de tiempo fijas. Sliding Window: ventana deslizante más precisa. Token Bucket: tokens que se regeneran. Leaky Bucket: cola de velocidad fija.</p> <h2 id="cabeceras-de-respuesta">Cabeceras de respuesta </h2><p><code>X-RateLimit-Limit</code>, <code>X-RateLimit-Remaining</code>, <code>X-RateLimit-Reset</code>. El cliente puede ajustar su comportamiento. HTTP 429 Too Many Requests con <code>Retry-After</code>.</p> <h2 id="implementación">Implementación </h2><p>Redis para rate limiting distribuido. Almacenamiento en memoria para single-server. Middleware en Express, FastAPI, Cloudflare Workers.</p>