Puedes definir puntos de conexión HTTPS personalizados para crear rutas de API o webhooks específicos de la aplicación que se integren con servicios externos. Un punto de conexión personalizado utiliza una función sin servidor que escribes para gestionar las solicitudes entrantes de una URL y un método HTTP específicos.
Nota
No se admiten endpoints HTTPS personalizados en nodos privados.
Endpoints use standard, encrypted HTTPS requests, which means that you don't need to install any database drivers or opinionated libraries to call them. Instead, you send requests like this from any HTTP client:
curl -s "https://data.mongodb-api.com/app/myapp-abcde/endpoint/hello" \ -X POST \ -H "Accept: application/json" \ -H "apiKey: TpqAKQgvhZE4r6AOzpVydJ9a3tB1BLMrgDzLlBLbihKNDzSJWTAHMVbsMoIOpnM6" \ -d '{ "name": "Casey" }'
Estructura de un punto final
Un punto final maneja uno o más métodos HTTP enviados a una URL específica.
URL base
Los puntos finales de una aplicación comparten una URL base. Esta URL usa el ID de la aplicación para dirigirse de forma única a ella.
Las aplicaciones distribuidas globalmente emplean el siguiente formato:
https://data.mongodb-api.com/app/<App ID>/endpoint
Los puntos finales en una aplicación implementada localmente usan una URL base específica para la región de implementación de la aplicación (por ejemplo, us-east-1)
https://<Region>.aws.data.mongodb-api.com/app/<App ID>/endpoint
Rutas de punto final
Cada endpoint HTTPS tiene una ruta que sirve como nombre para el endpoint. La ruta de un endpoint es arbitraria y específica de tu aplicación. Sin embargo, aparece en la ruta URL del endpoint y por lo tanto debe ser representativa de la acción que realiza la ruta.
Los nombres de las rutas deben comenzar con una barra diagonal (/) y pueden contener barras diagonales adicionales para indicar una ruta anidada.
/my/nested/route
Para llamar a un punto final, agregue su ruta a la URL base de su aplicación y envíe una solicitud HTTP.
https://data.mongodb-api.com/app/<App ID>/endpoint/my/nested/route
Métodos HTTP
Cada punto final de su aplicación maneja uno o más Métodos HTTPPara una ruta determinada. Por ejemplo, podría tener una sola ruta que acepte POST solicitudes para crear un nuevo recurso y una GET para listar los recursos existentes.
Puede definir varios puntos de conexión personalizados que sirvan a la misma ruta, pero que gestionen diferentes métodos de solicitud. También puede definir un único punto de conexión para la ruta que gestione todos los métodos.
Los endpoints personalizados soportan los siguientes métodos HTTP estándar:
Crear un punto final HTTPS personalizado
Puedes configurar la API de datos para tu aplicación desde la Interfaz de usuario Realm o implementando archivos de configuración con App Services CLI:
Haga clic HTTPS Endpoints en el menú de navegación de la izquierda y luego haga clic en Add An Endpoint.
Define el punto final Route. Los nombres de ruta deben comenzar con una barra diagonal (
/) y pueden contener barras diagonales adicionales para indicar una ruta anidada.Seleccione un método HTTP para el punto final en el menú desplegable. Puede elegir un método específico (p. ej.,
GETPOSTo) o configurar el punto final para que acepte cualquier método HTTP (p.ANYej.,).Elija un tipo de respuesta, JSON o EJSON. Puede habilitar Respond With Result para incluir automáticamente el valor de retorno de la función de punto final como cuerpo de la respuesta.
Escribe una función endpoint que gestione solicitudes para el endpoint. Como alternativa, especificar una función existente por su nombre.
Para mayor seguridad, puede configurar la autorización de solicitud.
Guardar la configuración de la API de datos.
Configura los permisos de acceso para permitir que las solicitudes lean y escriban datos de forma segura.
Guarde e implemente su aplicación.
Extrae la última versión de tu aplicación.
appservices pull --remote="<Your App ID>" Defina un objeto de configuración para el punto final personalizado.
http_endpoints/config.json[ { "route": "<Endpoint route name>", "http_method": "<HTTP method>", "function_name": "<Endpoint function name", "validation_method": "<Authorization scheme>", "respond_result": <boolean>, "fetch_custom_user_data": <boolean>, "create_user_on_auth": <boolean>, "disabled": <boolean> } ] Definir reglas para una o más colecciones.
data_sources/mongodb-atlas/<db>/<collection>/rules.json{ "database": "<Database Name>", "collection": "<Collection Name>", "roles": [<Role>], "filters": [<Filter>] } Implementa tu aplicación.
appservices push
Autenticación
Custom endpoints run in the context of a specific user, which allows your app to enforce rules and validate document schemas for each request.
Por defecto, los endpoints usan autenticación de la aplicación, lo que requiere que cada solicitud incluya credenciales para uno de tus usuarios de la aplicación, como una clave de API o JWT. También puedes configurar otros esquemas de autenticación personalizados para adaptarlos a las necesidades de tu aplicación.
Para obtener ejemplos de cómo autenticar solicitudes, consulte Autenticar solicitudes de API de datos.
La autenticación de la aplicación requiere que los usuarios inicien sesión con un proveedor de autenticación que haya habilitado para su aplicación. Las solicitudes pueden incluir un token de acceso otorgado por el proveedor de autenticación o las credenciales con las que el usuario iniciaría sesión (por ejemplo, su clave API o correo electrónico y contraseña).
La autenticación de ID de usuario ejecuta todas las solicitudes como un único usuario de aplicación preseleccionado. Esto resulta útil si todas las solicitudes deben tener los mismos permisos, independientemente de quién haya llamado al endpoint.
Para seleccionar el usuario, especifica su ID de cuenta de usuario en la configuración del endpoint.
[ { ..., "run_as_user_id": "628e47baf4c2ac2796fc8a91" } ]
La autenticación de scripts llama a una función para determinar el usuario de la aplicación al que se ejecuta una solicitud. Puede usar esto para implementar esquemas de autenticación y autorización personalizados.
La función debe devolver el ID de Cuenta de un usuario de aplicación existente como un string o { "runAsSystem": true } para ejecutar la solicitud como un usuario del sistema que tenga acceso total a las API de CRUD y Agregación de MongoDB y no esté sujeto a ninguna regla, rol o permisos limitados.
Para definir la función, especifique el código fuente en la configuración del punto final.
[ { ..., "run_as_user_id_script_source": "exports = () => {return \"628e47baf4c2ac2796fc8a91\"}" } ]
La autenticación del sistema configura un endpoint para ejecutarse como usuario del sistema que no requiere credenciales, tiene acceso completo a las API de MongoDB CRUD y Agregación, y no está sujeto a ninguna regla, rol o permisos limitados.
[ { ..., "run_as_system": true } ]
Tip
Los nuevos puntos finales que cree en la interfaz de usuario utilizan la autenticación del sistema de manera predeterminada.
Autorización
Un endpoint puede requerir que los usuarios autenticados brinden información adicional de autorización en la solicitud. Defines el esquema de autorización para cada endpoint personalizado configurando la función del endpoint.
Los endpoints admiten de forma nativa un conjunto de esquemas de autorización integrados que utilizan una cadena secreta para demostrar que la solicitud está autorizada. También puede definir un esquema de autorización personalizado que pueda usar junto con los esquemas integrados o en lugar de ellos.
Para aprender a configurar la autorización para una función específica, consulta Definir una función.
Esquemas de autorización integrados
Los endpoints admiten los siguientes esquemas de autorización incorporados:
Esquemas de autorización personalizados
Puedes definir una expresión de autorización personalizada para determinar si se permite la ejecución de una solicitud autenticada entrante. La expresión se evalúa para cada solicitud y debe dar true como resultado para permitirla. Si da como false resultado, la solicitud no se autoriza y falla con un error. Las solicitudes que no superan la autorización no se contabilizan para el uso facturado de tu aplicación.
Las expresiones de autorización pueden usar variables como %%user para autorizar en función de los datos del usuario que llama o %%request para tomar decisiones basadas en los detalles de cada solicitud entrante.
Para definir un esquema de autorización personalizado, especifique la expresión en la configuración de la función del punto final:
[ { ..., "can_evaluate": { "%%request.requestHeaders.x-secret-key": "my-secret" } } ]
Guardar una función endpoint
Cada endpoint personalizado está asociado con una función que se ejecuta cada vez que el endpoint recibe una solicitud entrante. En la función, puedes importar librerías desde npm, conectarte a un clúster MongoDB Atlas vinculado y llamar a otras funciones sin servidor.
Para definir una nueva función al crear un punto final en la interfaz de usuario de App Services, navegue a la Function sección y seleccione en el + New Function menú desplegable.
Dependiendo del flujo de trabajo, también puedes definir y editar funciones de gestión de endpoints:
En la Functions página de la interfaz de usuario de servicios de aplicaciones.
En el directorio
functionsde tu aplicación utilizando el CLI de App Services.Desde su cliente utilizando la API de administración.
Endpoint functions always receive two arguments:
Un objeto de solicitud que le permite acceder a los encabezados de solicitud entrantes, parámetros de consulta y datos del cuerpo.
Un objeto de respuesta que se utiliza para configurar la respuesta HTTPS que se envía al llamador.
Para ver una función de muestra y un ejemplo de solicitud y respuesta, consulte Ejemplo.
Datos de solicitud de acceso
A custom endpoint Request object represents the HTTP request that called the endpoint. You can access the incoming request's headers, query parameters, and body data.
{ "headers": { "<Header>": ["<Header Value>"] }, "query": { "<Query Parameter>": "<Parameter Value>" }, "body": <BSON.Binary> }
Campo | Descripción | |||||
|---|---|---|---|---|---|---|
| Un objeto donde cada campo asigna un parámetro de consulta URL a su valor. Si una clave se usa varias veces en la cadena de consulta, solo se representa la primera vez en este objeto. Para trabajar con la cadena de consulta completa, utilice context.request.rawQueryString. EjemploEl siguiente objeto | |||||
| Un objeto donde cada campo asigna un nombre de encabezado de solicitud a una matriz de uno o más valores. Ejemplo | |||||
| A BSON.Binary object that contains the request body. If the request did not include a body, this value is Para acceder a los datos en el cuerpo de la solicitud, debe serializar el binario: |
Devuelve una respuesta HTTPS
Un objeto de punto final personalizado Response permite configurar la respuesta HTTPS enviada al emisor. Se puede configurar el código de estado, personalizar los encabezados e incluir datos en el cuerpo de la respuesta.
Método | Descripción | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
setStatusCode(code)- code: number | Establece el código de estado.de la respuesta HTTP Ejemplo | |||||||||
setBody(body)- body: string | BSON.Binary | Establece el body.de la respuesta HTTP. Si Ejemplo | |||||||||
setHeader(name, value)- name: string- value: string | Establezca la respuesta HTTP encabezado especificado por Ejemplo | |||||||||
addHeader(name, value)- name: string- value: string | Establece la cabecera HTTP de respuesta especificada por Ejemplo |
Ejemplo
Considere una función de punto final que analiza el cuerpo de una solicitud POST entrante, almacena el cuerpo analizado en una colección MongoDB y luego responde al llamador:
exports = async function MyCustomEndpoint(request, response) { try { // 1. Parse data from the incoming request if (request.body === undefined) { throw new Error(`Request body was not defined.`); } const body = JSON.parse(request.body.text()); // 2. Handle the request const { insertedId } = await context.services .get("mongodb-atlas") .db("myDb") .collection("myCollection") .insertOne({ date: new Date(), requestBody: body }); // 3. Configure the response response.setStatusCode(201); // tip: You can also use EJSON.stringify instead of JSON.stringify. response.setBody( JSON.stringify({ insertedId, message: "Successfully saved the request body", }) ); } catch (error) { response.setStatusCode(400); response.setBody(error.message); } };
La función recibe la siguiente solicitud de POST:
curl -s "https://data.mongodb-api.com/app/myapp-abcde/endpoint/custom" \ -X POST \ -H "Accept: application/json" \ -H "apiKey: TpqAKQgvhZE4r6AOzpVydJ9a3tB1BLMrgDzLlBLbihKNDzSJWTAHMVbsMoIOpnM6" \ -d '{ "type": "event", "date": "2024-01-01T00:00:00.000Z", "name": "New Year Begins", "comment": "Happy New Year!" }'
{ "message": "Successfully saved the request body", "insertedId": "639a521bbdec9b85ba94014b" }
After the function verifies that the body of the incoming request is defined, it stores the parsed body as a new document in a collection named myCollection. The resulting output displays the configured response, which includes a custom message and the insertedId.
Call a Custom Endpoint
Puede llamar a un punto final personalizado desde cualquier cliente HTTPS estándar.
curl -s "https://data.mongodb-api.com/app/myapp-abcde/endpoint/hello" \ -X POST \ -H "Accept: application/json" \ -H "apiKey: TpqAKQgvhZE4r6AOzpVydJ9a3tB1BLMrgDzLlBLbihKNDzSJWTAHMVbsMoIOpnM6" \ -d '{ "name": "Casey" }'
Se requiere HTTP/1.1 o superior al realizar solicitudes.
Elija un formato de datos de respuesta
A request can include an Accept header to request a specific data format for the response body, either JSON or EJSON. If a request does not include a valid Accept header, the response uses the default data format specified in the endpoint configuration.
curl -s "https://data.mongodb-api.com/app/myapp-abcde/endpoint/hello/latest" \ -X GET \ -H "Accept: application/ejson" \ -H "apiKey: TpqAKQgvhZE4r6AOzpVydJ9a3tB1BLMrgDzLlBLbihKNDzSJWTAHMVbsMoIOpnM6"
{ "greeting": "Hello, Leafie!", "date": { "$date": { "$numberLong": "1654589430998" } } }
curl -s "https://data.mongodb-api.com/app/myapp-abcde/endpoint/hello/latest" \ -X GET \ -H "Accept: application/json" \ -H "apiKey: TpqAKQgvhZE4r6AOzpVydJ9a3tB1BLMrgDzLlBLbihKNDzSJWTAHMVbsMoIOpnM6"
{ "greeting": "Hello, Leafie!", "date": "2022-06-07T08:10:30.998Z" }
Autenticar la solicitud
Si un punto final está configurado para usar la autenticación de aplicaciones, debe incluir un token de acceso de usuario válido o credenciales de inicio de sesión con cada solicitud.
En general, la autenticación de portador con un token de acceso ofrece mayor rendimiento y es más segura que los encabezados de credenciales. Utilice un token de acceso en lugar de encabezados de credenciales siempre que sea posible. El token permite ejecutar múltiples solicitudes sin tener que volver a autenticar al usuario. También permite enviar solicitudes desde un navegador web que implemente CORS.
Para usar un token de acceso, primero autentique al usuario mediante un proveedor de autenticación de App Services. Luego, obtenga el token de acceso devuelto por App Services e inclúyalo en el encabezado de autorización de la solicitud mediante un esquema de token de portador. Para obtener más información sobre cómo adquirir y usar un token de acceso,consulte Autenticación de token de portador.
curl -X GET \ -H 'Authorization: Bearer <AccessToken>' \ -H 'Content-Type: application/json' \ https://data.mongodb-api.com/app/myapp-abcde/endpoint/hello
Otra opción es incluir credenciales de inicio de sesión válidas para el usuario en las cabeceras de la solicitud.
curl -s "https://data.mongodb-api.com/app/myapp-abcde/endpoint/hello" \ -X POST \ -H "Accept: application/json" \ -H "email: bob@example" \ -H "password: Pa55w0rd!" \ -d '{ "name": "Bob" }'
curl -s "https://data.mongodb-api.com/app/myapp-abcde/endpoint/hello" \ -X POST \ -H "Accept: application/json" \ -H "apiKey: TpqAKQgvhZE4r6AOzpVydJ9a3tB1BLMrgDzLlBLbihKNDzSJWTAHMVbsMoIOpnM6" \ -d '{ "name": "Alice" }'
curl -s "https://data.mongodb-api.com/app/myapp-abcde/endpoint/hello" \ -X POST \ -H "Accept: application/json" \ -H "jwtTokenString: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJ0ZXN0LWN1c3RvbS1lbmRwb2ludHMtZWhtenQiLCJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiZXhwIjoyMTQ1OTE2ODAwfQ.pIMvnXWrcDvmPzmE33ZPrwkBAFSwy-GxW8sP-qLtYiw" \ -d '{ "name": "Carlos" }'
Importante
No uses claves API en clientes orientados al usuario
Si se autentica desde un navegador u otra aplicación cliente, evite usar una clave API para iniciar sesión. En su lugar, utilice otro proveedor de autenticación que acepte las credenciales proporcionadas por el usuario. Nunca almacene localmente claves API ni otras credenciales confidenciales.
Autorizar la solicitud
Dependiendo de la configuración del punto final, es posible que sus solicitudes deban incluir información de autorización adicional.