¿Qué es un endpoint de API?

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

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:

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 / 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 — Back4app Flutter SDK
// Every class gets endpoints automatically — this call hits one
final query = QueryBuilder<ParseObject>(ParseObject('Todo'))
  ..whereEqualTo('done', false)
  ..setLimit(10);
final response = await query.query();
// Endpoint used: GET /classes/Todo?where={"done":false}&limit=10

// 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

// Android / Kotlin — Back4app Android SDK
// Every class gets endpoints automatically — this call hits one
val query = ParseQuery.getQuery<ParseObject>("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:

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 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.

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:

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.

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:

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 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: 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, 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

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 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 — 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.