--- term: 'Endpoint de API' seoTitle: '¿Qué es un Endpoint de API? Anatomía, Ejemplos y Buenas Prácticas' headline: '¿Qué es un endpoint de API?' slug: endpoint-de-api category: api-realtime shortDefinition: 'Un endpoint de API es una URL específica donde una API recibe solicitudes para un recurso — junto con un método HTTP, define una operación.' relatedTerms: - api - rest-api - api-gateway-architecture - auto-generated-database-apis contrastsWith: - api-gateway-architecture aboutTerms: - 'URL Base' - 'Parámetros de Path' - 'Parámetros de Query' faq: - question: '¿Qué es un endpoint de API, en términos simples?' answer: 'La URL específica donde una API recibe solicitudes sobre un recurso — cada endpoint es una puerta de entrada a la API. Una solicitud a /users/42 con el método GET pide los datos del usuario 42; el mismo path con DELETE pide eliminarlo. La API es el edificio completo; los endpoints son sus puertas direccionables.' - question: '¿Cuál es un ejemplo de endpoint de API?' answer: 'https://api.example.com/v1/users/42 — una URL base (esquema más host más versión) y luego un path que nombra el recurso. Equivalentes del mundo real: el endpoint /repos/OWNER/REPO de una plataforma de hospedaje de código, o el endpoint /classes/Todo que una app de Back4app genera automáticamente para una clase de datos Todo.' - question: '¿Cuál es la diferencia entre una API y un endpoint?' answer: 'La API es el contrato entero — el conjunto completo de reglas, recursos y operaciones que un servicio expone. Un endpoint es un punto de acceso específico dentro de ella. Una API expone muchos endpoints, y la documentación de una API es, en gran parte, un catálogo de ellos.' - question: '¿Un endpoint es lo mismo que una URL?' answer: 'No exactamente. El endpoint se expresa como una URL, pero la URL es solo la dirección; el endpoint es el punto de interacción que esa dirección identifica. La documentación suele escribir los endpoints como paths con la URL base implícita — y, en rigor, el método HTTP es parte de lo que define la operación en esa dirección.' - question: '¿La misma URL puede ser más de un endpoint?' answer: 'Sí. GET /users/42 y DELETE /users/42 comparten la URL pero son operaciones distintas — por eso el estándar OpenAPI modela una API como paths, cada uno con múltiples operaciones indexadas por método. Cuando alguien cuenta "endpoints", normalmente está contando operaciones.' - question: '¿Cuál es la diferencia entre un endpoint y una ruta?' answer: 'Perspectiva. La ruta es la definición del lado del servidor — un patrón de path, un método y una función handler en tu framework. El endpoint es la URL de cara al cliente donde esa ruta es alcanzable. La misma cosa, vista desde los dos extremos opuestos de la solicitud.' - question: '¿Cómo encuentro los endpoints de una API?' answer: 'Tres caminos, en orden de confiabilidad: leer la documentación o la especificación OpenAPI legible por máquinas, que enumera cada path y operación; observar el tráfico real en la pestaña de red de las herramientas de desarrollo del navegador, filtrada por fetch/XHR; o ejercitar llamadas con curl y un cliente de API para confirmar el comportamiento.' - question: '¿Cómo se protege un endpoint de API?' answer: 'Trata cada endpoint como superficie de ataque: solo HTTPS, autenticación en cada ruta, autorización acotada al privilegio mínimo, validación de entrada, rate limits, paginación con límites y mensajes de error que no filtren detalles internos. Luego mantén un inventario — los endpoints "zombis" olvidados están entre las principales fallas de seguridad de API.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'RFC 3986 — URI: Generic Syntax' url: 'https://datatracker.ietf.org/doc/html/rfc3986' - name: 'RFC 9110 — HTTP Semantics' url: 'https://www.rfc-editor.org/rfc/rfc9110' - name: 'OpenAPI Specification — Paths and Operations' url: 'https://spec.openapis.org/oas/latest.html#paths-object' - name: 'OWASP API Security Top 10' url: 'https://owasp.org/API-Security/' cta: title: 'Endpoints que nunca tuviste que diseñar' text: 'Crea una clase en Back4app y sus endpoints REST existen de inmediato — URLs de recurso, métodos, auth y permisos a cargo de la plataforma, consistentes en todo tu modelo de datos.' linkText: 'Empieza gratis' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-08-31' translationKey: api-endpoint --- **Un endpoint de API es una URL específica donde una API recibe solicitudes para un recurso — junto con un método HTTP, define una operación.** Esa segunda cláusula es la parte que la mayoría de las definiciones omite, y es la que resuelve la confusión clásica: `GET /users/42` y `DELETE /users/42` comparten una dirección pero son endpoints distintos, igual que una puerta se comporta diferente según toques o gires la llave. ## Puntos clave | Pregunta | Respuesta | | --- | --- | | La fórmula | URL base + path (+ método) = una operación sobre un recurso | | vs. la API | API = el contrato entero · endpoint = un punto de acceso dentro de ella | | Path vs. query | El path identifica *qué* recurso · la query dice *cómo* retornarlo | | Nomenclatura | Sustantivos en plural, minúsculas, anidamiento superficial — el verbo lo lleva el método | | Seguridad | Cada endpoint es superficie de ataque — incluidos los olvidados | ## Anatomía de la URL de un endpoint de API Cada pieza de una URL de solicitud real, etiquetada — según la gramática de la [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986): ```text GET https://api.example.com/v1/users/42/posts?status=published&limit=20 GET método — la acción; parte de la identidad de la operación https esquema — TLS, innegociable api.example.com host ┐ la URL base, compartida por /v1 versión ┘ todos los endpoints de la API /users/42/posts path — el recurso: posts del usuario 42 42 parámetro de path — identifica QUÉ recurso ?status=published parámetros de query — CÓMO retornarlo: &limit=20 filtrar, ordenar, paginar (fuera de la identidad) ``` Llamar a un endpoint desde el código de la aplicación — el SDK compone la URL, el método y la auth por ti: **JavaScript:** ```javascript // JavaScript / Node.js — Back4app JS SDK // Every class gets endpoints automatically — this call hits one const query = new Parse.Query('Todo'); query.equalTo('done', false); query.limit(10); const todos = await query.find(); // Endpoint used: GET /classes/Todo?where={"done":false}&limit=10 ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK // Every class gets endpoints automatically — this call hits one final query = QueryBuilder(ParseObject('Todo')) ..whereEqualTo('done', false) ..setLimit(10); final response = await query.query(); // Endpoint used: GET /classes/Todo?where={"done":false}&limit=10 ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK // Every class gets endpoints automatically — this call hits one let query = Todo.query("done" == false) .limit(10) let todos = try await query.find() // Endpoint used: GET /classes/Todo?where={"done":false}&limit=10 ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // Every class gets endpoints automatically — this call hits one val query = ParseQuery.getQuery("Todo") query.whereEqualTo("done", false) query.limit = 10 val todos = query.find() // Endpoint used: GET /classes/Todo?where={"done":false}&limit=10 ``` ## Endpoint vs. API vs. URL vs. ruta La desambiguación a cuatro bandas que ninguna página de ranking ofrece por sí sola: | Término | Qué es | Vocabulario de quién | | --- | --- | --- | | API | El contrato entero: todos los recursos, operaciones y reglas | De todos | | Endpoint | Un punto de acceso — una URL (+ método) que recibe solicitudes para un recurso | La vista de quien consume | | URL | La cadena de dirección que localiza el endpoint ([RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986)) | La vista del cable | | Ruta | La definición server-side: patrón de path + método + código del handler | La vista de quien implementa | Endpoint y ruta son la misma cosa vista desde extremos opuestos: un framework declara una ruta, un cliente llama a un endpoint. Y la [OpenAPI Specification](https://spec.openapis.org/oas/latest.html#paths-object) formaliza el cuadro completo — una API es un conjunto de *paths*, cada path contiene *operaciones* indexadas por método, y "¿cuántos endpoints tiene esta API?" es en realidad un conteo de operaciones. ```mermaid flowchart LR accTitle: Cómo una solicitud llega a un recurso a través de un endpoint accDescr: Una solicitud del cliente con método y URL llega a la URL base de la API, se empareja con la ruta de un endpoint por path y método, pasa autenticación y validación, y el handler opera sobre el recurso subyacente antes de devolver una respuesta. C["Cliente
GET /v1/users/42/posts"] --> B["URL base de la API
emparejamiento de ruta: path + método"] B --> A["Auth · validación
rate limits"] A --> H["Handler
(el código de la ruta)"] H --> R[("Recurso:
posts del usuario 42")] R --> H --> C ``` ## Parámetros de path vs. parámetros de query La regla que zanja la mayoría de los debates de diseño — **identidad en el path, modificación en la query**: | Pregunta que responde el parámetro | Pertenece a | Ejemplo | | --- | --- | --- | | ¿*Qué* recurso? | Path | `/users/42`, `/orders/2026-1187` | | ¿Qué colección *relacionada*? | Path | `/users/42/posts` | | ¿Filtrar los resultados? | Query | `?status=published` | | ¿Ordenar o paginar? | Query | `?sort=-createdAt&limit=20` | | ¿Ajustes opcionales de comportamiento? | Query | `?include=author&fields=title` | La distinción tiene consecuencias: los parámetros de path forman parte de la identidad del recurso (y de la clave de caché); los parámetros de query moldean la representación. Un recurso alcanzable solo vía query string (`/getData?type=user&id=42`) es el clásico olor a nivel 0 del que parte la escalera de madurez [REST](/glossary/es/api-rest/). ## Cómo nombrar bien tus endpoints Los consumidores califican una API por su lista de endpoints antes de leer una palabra de la documentación: | Convención | Bien | Mal | | --- | --- | --- | | Sustantivos, no verbos — el verbo es el método | `POST /orders` | `POST /createOrder` | | Colecciones en plural | `/users`, `/users/42` | `/user/42` | | Minúsculas, con guiones | `/purchase-orders` | `/PurchaseOrders`, `/purchase_orders` | | Anidamiento superficial (un nivel) | `/users/42/posts` | `/users/42/posts/8/comments/3/likes` | | Prefijo de versión con política | `/v1/…` + ventanas de deprecación | Romper la `/v1` en silencio | | Patrones predecibles | La misma forma para cada recurso | Cada recurso con su propio dialecto | ## Proteger endpoints: el checklist Cada endpoint es una puerta, y los atacantes las prueban todas — incluidas las que olvidaste. El checklist compacto: **solo HTTPS**; **autenticación en cada endpoint** (sin excepciones "internas" alcanzables desde internet); **autorización por recurso**, no solo por API — el usuario 42 leyendo `/users/43/orders` es el clásico agujero de broken object level authorization; **validación de entrada** en path, query y body; **[rate limits](/glossary/api-rate-limiting-throttling/)** dimensionados según el costo del endpoint; **paginación con límites** para que ningún endpoint devuelva colecciones sin techo; **higiene de errores** (sin stack traces, sin filtrar existencia). Y el punto que los equipos pasan por alto: **inventario**. Los endpoints "zombis" — sin documentar, deprecados pero vivos — tienen su propia entrada en el [OWASP API Security Top 10](https://owasp.org/API-Security/): un endpoint que no recuerdas es un endpoint que no defiendes. ## Casos de uso comunes Dónde pensar en endpoints se gana su lugar: - **Consumir una API de terceros** — el catálogo de endpoints de la documentación *es* el producto; dominar la anatomía es la forma de leerlo. - **Diseñar una API pública** — decisiones de nomenclatura, ubicación de parámetros y versionado con las que los consumidores conviven durante años. - **Depurar integraciones** — reproducir una llamada del SDK como solicitud cruda al endpoint con curl separa las fallas del cliente de las del servidor. - **Configurar gateway y monitoreo** — los [rate limits](/glossary/api-gateway-architecture/), las alertas y las reglas de acceso se declaran por endpoint. - **Auditorías de seguridad** — el inventario de endpoints es el mapa de la superficie de ataque; la auditoría empieza por enumerarlo. ## ¿Debería ser un nuevo endpoint? Matriz de decisión | Situación | Respuesta | | --- | --- | | Nuevo tipo de recurso | Nuevo endpoint (`/invoices`) | | Mismo recurso, resultados más acotados | Endpoint existente + parámetros de query | | Misma URL, acción distinta | Mismo path, método distinto | | Una pantalla necesita cinco endpoints | Considera un endpoint compuesto — pero mira el sprawl, abajo | | Representación variante (campos, formato) | Parámetro de query o negociación de contenido, no un path nuevo | | Cambio que rompe forma o semántica | Nuevo prefijo de versión, con ventana de deprecación | ## Limitaciones y trade-offs - **El sprawl de endpoints es deuda real.** Los endpoints por pantalla y por equipo se acumulan; cada uno es documentación, pruebas, monitoreo y superficie de ataque para siempre. Pocos endpoints bien diseñados vencen a muchos hechos a la medida. - **Las formas fijas les quedan mal a algunos consumidores.** Un endpoint devuelve lo que devuelve — el trade-off de [overfetching/underfetching](/glossary/overfetching-underfetching/) que las APIs con forma de consulta existen para responder. - **Las URLs son contratos.** Renombrar un endpoint rompe a todos los consumidores; diseña nombres con los que puedas vivir, porque migrar significa versionado, redirecciones y calendarios de deprecación. - **El método es invisible en el habla casual.** "El endpoint /users" esconde si hablas de lectura o de escritura — la precisión importa en documentación, logs y reglas de seguridad. - **Contar endpoints no mide nada.** Una API con 12 endpoints coherentes le gana rutinariamente a una con 400 improvisados; la señal de calidad es la gobernanza, no el volumen. ## Endpoints de API en Back4app Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. Aquí los endpoints se *derivan, no se diseñan*: crear una clase `Todo` expone al instante `/classes/Todo` y `/classes/Todo/:objectId` con el juego completo de métodos — el patrón de [APIs generadas automáticamente](/glossary/es/apis-generadas-automaticamente/) — más endpoints permanentes para usuarios, sesiones, archivos y funciones, todos compartiendo una única URL base, autenticación por keys y permisos por clase. Las pestañas de código muestran la consecuencia práctica: el SDK compone endpoint, método y credenciales por ti, y el checklist de arriba — consistencia de nombres, auth en todo, queries con límites, cero zombis — llega como comportamiento de la plataforma y no como disciplina de revisión de código. Las operaciones personalizadas obtienen endpoints de la misma manera: despliega una función de Cloud Code y `/functions/tuFuncion` pasa a existir.