La API pública de Cloud Manager sigue los principios de la arquitectura REST para exponer recursos internos que brindan acceso programático a las funciones de Cloud Manager.
Al igual que con los cambios realizados a través de la interfaz web, los cambios realizados a través de la API están sujetos a Cloud Manager. Precios. Si agrega servidores y genera cargos, debe tener una tarjeta de crédito válida registrada en Cloud Manager o corre el riesgo de que su cuenta sea bloqueada.
La API tiene las siguientes características:
- EntidadesJSON
- Todas las entidades se expresan en JSON.
- Interfaz navegable
- Al utilizar un mecanismo de enlace consistente, puede explorar toda la API comenzando en el recurso raíz y siguiendo los enlaces a los recursos relacionados.
- Control de acceso de usuarios
Las capacidades de API de cada usuario de Cloud Manager coinciden con los permisos que otorgan sus roles de Cloud Manager.
- Lista de acceso a la redAPI
La API de Cloud Manager puede proteger el acceso a la API de administración de Cloud Manager mediante una lista de acceso a la API. Esta lista restringe el acceso a la API a direcciones IP o CIDR específicas. Cada clave de API tiene su propia lista de acceso a la API de administración de Cloud Manager. Al crear una nueva organización mediante la interfaz de usuario de Cloud Manager, MongoDB Atlas habilita el requisito de la lista de acceso a la API de forma predeterminada.
Para aprender más, consulte (Opcional) Requerir una lista de acceso a API para su organización.
- SóloHTTPS
- Solo se puede acceder a la API a través de HTTPS, lo que garantiza que todos los datos enviados a través de la red estén completamente encriptados mediante TLS.
MétodosHTTP
Todos los recursos admiten un subconjunto de estos métodos HTTP comunes:
Método | Propósito |
|---|---|
| Recupera la representación JSON de un recurso. |
| Cree un nuevo recurso utilizando la representación JSON proporcionada. |
| Reemplace un recurso con la representación JSON proporcionada. |
| Actualice los campos especificados en un recurso utilizando la representación JSON proporcionada. |
| Eliminar un recurso. |
| Recupere el encabezado de respuesta sin la representación JSON del recurso. |
JSON
Todas las entidades se representan en JSON. Se aplican las siguientes reglas para solicitudes y convenciones de respuesta:
Reglas de solicitud
- Aplicar el encabezado de tipo de contenido correcto
- Al enviar JSON al servidor a través
POSTde o,PUTasegúrese de especificar el encabezado de solicitud de tipo de contenido correcto:Content-Type: application/json - Establecer fechas como ISO 8601 Instrumentos de cuerda
Al enviar fechas al servidor (como parámetros de consulta o campos en entidades de solicitud
POSTPATCHo), utilice fechas formateadas según el estándar ISO. Si no especifica una zona horaria, Cloud Manager 8601 asume que es UTC. Incluya un indicador de zona horaria para evitar ambigüedades.Ejemplo
Septiembre 27, 2018 se expresa como
2018-09-27.El 27 de septiembre de 2018 a las 4:00 p. m. EDT se expresa (con zona horaria) como
2018-09-27T16:00-04:00.
En algunos casos, una marca de tiempo se devuelve como una representación JSON de una marca de tiempo BSON, especialmente en los recursos de copia de seguridad. Esta representación de una marca de tiempo BSON proporciona un documento JSON como un objeto con dos campos:
CampoDefinicióndateSegundos desde la Unix epoch
incrementUn ordinal entero incremental de 32bits para operaciones dentro de un segundo determinado.
Ejemplo
La tercera operación el 27 de septiembre de 2018 a las 4:00 PM EDT se expresa (con zona horaria) como
{ date: 2018-09-27T16:00-04:00, increment: 3 }
Convenciones de respuesta
- Rechaza campos inválidos
Los campos no válidos se rechazan en lugar de ignorarse.
Ejemplo
Intenta crear una nueva entidad y escribe mal uno de los campos, o si intenta actualizar una entidad existente e incluye un campo que no se puede modificar, Cloud Manager responde con un 400 código de estado HTTP y un mensaje de error que indica qué campo no es válido.
- Devuelve fechas como cadenas ISO 8601
- Todas las fechas se devuelven como cadenas con formato ISO 8601 designadas en UTC.
- Campo de etiquetas para desambiguar unidades
Los campos que contienen valores numéricos en una unidad particular se nombran de manera tal de desambiguar la unidad que se está utilizando.
Ejemplo
El tiempo de actividad de un host se devuelve en milisegundos, por lo que el nombre del campo de entidad del host es
uptimeMsec.- Devuelve valores predeterminados para campos sin otros valores
Los campos que no tienen un valor actual se devuelven con un valor por defecto apropiado.
Ejemplo
Cloud Manager no tiene ninguna estadística para un host recién descubierto, por lo que cualquier campo relacionado con las estadísticas tiene un valor de cero.
Se omiten los campos que no tienen un valor por defecto razonable en la entidad.
Ejemplo
Un host que no utiliza autenticación omite el campo
usernamede la entidad devuelta.- Devuelve campos en orden alfabético
- Los campos de los documentos JSON que devuelve Cloud Manager están en orden alfabético. El orden puede variar. No dependa del orden de los campos.
Enlace
Cada recurso incluye uno o más enlaces a subrecursos y/o recursos relacionados.
Ejemplo
Un host tiene un enlace al proyecto al que pertenece, al conjunto de réplicas al que pertenece, etc.
Los enlaces se colocan en el campo links de una entidad, que es una matriz de objetos de relación de enlace. Cada relación de enlace tiene dos campos:
Campo | Definición |
|---|---|
| Nombre (o tipo) de la relación. Muchos de estos se consideran como Tipos de Relaciones de Extensión y tienen el prefijo |
| URL de destino. |
Todas las entidades incluyen al menos una relación de enlace self llamada, que es simplemente su propia URL. Cuando una entidad forma parte de una lista (es decir, al solicitar todos los hosts de un proyecto), solo incluye la self relación de enlace.
Ejemplo
Esta es una parte de un recurso host con algunos enlaces:
1 { 2 "id": "xxx", 3 "projectId": "yyy", 4 "hostname": "mongodb.example.com", 5 "port": 27017, 6 "links": [ 7 { 8 "rel": "self", 9 "href": "https://cloud.mongodb.com/api/public/v1.0/projects/xxx/hosts/yyy" 10 }, 11 { 12 "rel": "http://mms.mongodb.com/project", 13 "href": "https://cloud.mongodb.com/api/public/v1.0/projects/xxx" 14 } 15 ] 16 }
Para obtener más información, consulte la Especificación de enlaces web.
Nota
Aunque la Especificación de Enlaces Web describe un formato para incluir enlaces en los encabezados de respuesta HTTP, no es obligatorio. Para facilitar la navegación por la API, incluye los enlaces en el cuerpo de la respuesta en lugar de en los encabezados.
Listas
Algunos recursos devuelven una lista de entidades.
Ejemplo
Puedes solicitar una lista de todos los hosts en un Proyecto.
Cuando se espera una lista de entidades en una respuesta, los resultados se devuelven en lotes delimitados por dos parámetros de consulta:
Campo | Definición |
|---|---|
| Número de página (basado en 1). El valor predeterminado es 1 si no se especifica. |
| Número de elementos a devolver por página, hasta un máximo de 500. El valor predeterminado es 100 si no se especifica. |
La entidad de respuesta contiene tres campos:
Campo | Definición |
|---|---|
| Número total de elementos en todo el conjunto de resultados. Por ejemplo, si un proyecto tiene un total de 57 hosts y realiza una solicitud con |
| Conjunto de resultados, que es una matriz de documentos de entidad. |
| Contiene de una a tres relaciones de enlace:
|
Si solicitas una lista de entidades y no hay resultados, la API responde con un HTTP código de estado 200 y un results arreglo vacío. No responde con un 404 en este caso, ya que la lista de entidades puede no estar vacía en el futuro.
Si ha solicitado una lista de entidades en un contexto que no existe (es decir, la lista de hosts de un proyecto inexistente), esto genera un 404 estado de respuesta HTTP.
Ejemplo
Esta es una respuesta HTTP para la segunda página de 10 hosts en un proyecto con un total de 57 hosts:
1 { 2 3 "totalCount": 57, 4 "results": [ 5 { 6 "id": "yyy", 7 "projectId": "xxx", 8 // additional host properties... 9 }, 10 // additional host documents... 11 ], 12 "links": [ 13 { 14 "rel" : "self", 15 "href" : "https://www.mongodb.com/api/public/v1.0/projects/xxx/hosts?pageNum=2&itemsPerPage=10" 16 }, 17 { 18 "rel": "previous", 19 "href": "https://www.mongodb.com/api/public/v1.0/projects/xxx/hosts?itemsPerPage=10&pageNum=1" 20 }, 21 { 22 "rel": "next", 23 "href": "https://www.mongodb.com/api/public/v1.0/projects/xxx/hosts?itemsPerPage=10&pageNum=3" 24 } 25 ] 26 }
Sobres
Es posible que algunos clientes no puedan acceder a los encabezados de respuesta HTTP ni al código de estado. En ese caso, puede solicitar que la respuesta incluya envelope un, que es simplemente una capa adicional de información en el documento JSON que contiene los detalles relevantes que normalmente se encontrarían en los encabezados de respuesta.
De forma predeterminada, la API no incluye la respuesta en un sobre. Para solicitarlo, simplemente añada el parámetro de envelope=true consulta.
Para las respuestas que contienen una sola entidad, el sobre contiene dos campos:
Campo | Definición |
|---|---|
| HTTP status code. |
| Entidad solicitada. |
Para las respuestas que contienen una lista de entidades, ya existe un sobre que envuelve los resultados, por lo que especificar envelope=true como parámetro de consulta en este caso solo agrega el campo status al sobre existente.
Formateo legible
De forma predeterminada, los espacios en blanco superfluos se eliminan del JSON que devuelve Cloud Manager. Para solicitar un JSON con formato preimpreso, simplemente añada el pretty=true parámetro de consulta a cualquier solicitud:
curl --user '{PUBLIC-KEY}:{PRIVATE-KEY}' --digest \ --header 'Accept: application/json' \ --include \ --request GET "https://cloud.mongodb.com/api/public/v1.0?pretty=true"
Nota
Todos los ejemplos de este documento muestran JSON impreso con claridad, aunque algunas URLde ejemplo pueden no contener este parámetro de consulta adicional.
Códigos de respuesta
Las respuestas utilizan los códigos de respuesta HTTP estándar, incluidos:
Código | Significado | notas |
|---|---|---|
200 | Vale | La solicitud fue exitosa. Esta es la respuesta típica a una solicitud |
201 | Creado. | Se creó un nuevo recurso. Esta es la respuesta típica a una solicitud |
202 | Aceptado | Se aceptó una solicitud para una operación asincrónica. |
400 | Solicitud de mala | Algo estaba mal con la solicitud del cliente. |
401 | No autorizado | Se requiere autenticación, pero no estaba presente en la solicitud. Normalmente, esto significa que la información de autenticación digest fue omitida de la solicitud, las credenciales proporcionadas son incorrectas o el usuario asociado con la clave API dada no está autorizado para acceder al recurso solicitado. |
403 | Forbidden | No se permite el acceso al recurso especificado. |
404 | Not Found | El recurso solicitado no existe. |
405 | Método no permitido | El método HTTP no es compatible con el recurso especificado. Tenga en cuenta que cada recurso puede admitir solo un subconjunto de métodos HTTP. Por ejemplo, no se le permite |
409 | Conflicto | Normalmente, esta es la respuesta a una solicitud para crear o modificar una propiedad de una entidad que es única cuando ya existe una entidad con el mismo valor para esa propiedad. Por ejemplo, si intenta crear un proyecto con el mismo nombre que un proyecto existente, la solicitud falla. |
5xx | Varios errores del servidor | Se produjo un error inesperado. Inténtalo de nuevo más tarde y considera avisar al soporte de Cloud Manager. |
Errors
Cuando una solicitud genera un error, el cuerpo de la respuesta contiene un documento JSON con detalles adicionales sobre el problema. El documento contiene cinco campos:
Campo | Tipo de dato | Definición |
|---|---|---|
| string | Descripción legible por humanos del error de solicitud de API. |
| entero | HTTP código de estado. |
| string | Constante con nombre que representa el error de solicitud de API como se muestra en los Códigos de error de la API de administración de Cloud Manager. |
| matriz de cadenas | Lista de parámetros pasados en la solicitud de API. |
| string |
Ejemplo
Cloud Manager devuelve este cuerpo de respuesta para una solicitud con formato incorrecto:
1 { 2 "detail" : "Cannot find resource /api/public/v1.0/softwareComponents/version.", 3 "error" : 404, 4 "errorCode" : "RESOURCE_NOT_FOUND", 5 "parameters" : [ "/api/public/v1.0/softwareComponents/version" ], 6 "reason" : "Not Found" 7 }
Para revisar la lista de códigos, consulta Códigos de error de la API de administración de Cloud Manager.
Autenticación
La API de Cloud Manager utiliza uno de dos métodos para autenticar las solicitudes: claves de API o cuentas de servicio. Esto garantiza que las claves y los tokens de acceso que sirven como nombres de usuario y contraseñas nunca se envíen a través de la red. Para obtener más información sobre su uso, consulte Acceso programático a Cloud Manager con una cuenta de servicio.
Cuenta de servicio | Claves de API |
|---|---|
Nuevo método de autenticación en Cloud Manager utilizando el protocolo estándar de la industria OAuth 2.0 con el flujo de credenciales del cliente. | Método heredado de autenticación en Cloud Manager que utiliza autenticación de resumen HTTP. |
Una cuenta de servicio le permite administrar permisos y crear tokens de acceso. Una cuenta de servicio tiene un ID de cliente y un secreto que funcionan como nombre de usuario y contraseña para crear tokens de acceso. Un token de acceso le permite realizar solicitudes de API a Cloud Manager. | Las clavesAPI constan de dos partes: una clave pública y una clave privada. Estas dos partes cumplen la misma función que un nombre de usuario y una contraseña al realizar solicitudes API a Cloud Manager. |
Después de crear una cuenta de servicio, usarás su ID de cliente y secreto para generar un token de acceso, que autentica tus solicitudes API. Los tokens de acceso solo son válidos durante 1 hora (3600 segundos) según la especificación OAuth 2.0. La expiración de los tokens de acceso previene ataques de repetición, en los que un token de acceso filtrado podría usarse sin una restricción temporal. | Cloud Manager crea un hash de la clave pública y la clave privada mediante un valor único llamado nonce. Este nonce solo es válido durante un breve periodo, según la especificación HTTP digest. Esto sirve para evitar ataques de repetición, por lo que no se puede almacenar en caché un nonce y usarlo indefinidamente. |
Los roles de Cloud Manager limitan las operaciones que una cuenta de servicio puede realizar con su token de acceso. Debes asignar roles a las cuentas de servicio, igual que a los usuarios, para garantizar que el token de acceso pueda llamar a los puntos de conexión de la API sin errores. | Los roles de Cloud Manager limitan las operaciones que pueden realizar las claves de API. Debe asignar roles a las claves de API, tal como lo haría con los usuarios, para garantizar que estas puedan llamar a los puntos de conexión de la API sin errores. |
Cloud Manager vincula muchos recursos a un proyecto. Muchas URL de recursos de API siguen el formato. | Cloud Manager vincula muchos recursos a un proyecto. Muchas URL de recursos de API siguen el formato. |
Cada cuenta de servicio pertenece a una sola organización, pero puede otorgarle a una cuenta de servicio acceso a cualquier cantidad de proyectos en esa organización. | Cada clave API pertenece a una sola organización, pero puedes otorgar acceso a claves API a cualquier cantidad de proyectos en esa organización. |
Algunos métodos de recursos exigen mayor seguridad y están protegidos adicionalmente por listas de acceso que permiten el acceso al recurso solo desde las direcciones IP enumeradas. Cada usuario configura su propia lista de direcciones IP que permite el acceso al recurso.
Automatización
Los recursos "Recurso de configuración de automatización" y "Obtener el estado de automatización del último plan" proporcionan puntos finales que permiten modificar la implementación de un proyecto y recuperar su estado. Puede modificar una implementación enviando una nueva configuración de automatización a Cloud Manager. La configuración de automatización es donde se describen y configuran los procesos de MongoDB que se implementarán. Cloud Manager se refiere a esto como el "estado objetivo" de la implementación. Al enviar una nueva configuración de automatización a través de la API, las automatizaciones ajustan el estado actual del sistema para que coincida con el estado objetivo.
Importante
La API no cuenta con protección para evitar modificaciones simultáneas. Si dos administradores comienzan con una configuración basada en la versión actual, realizan sus propias modificaciones y luego las envían, prevalecerá la última modificación.
Limitación de velocidad
Ciertos recursos están sujetos a limitaciones de velocidad.
Para recursos con límite de velocidad, Cloud Manager permite hasta 100 solicitudes por minuto por proyecto. Tenga en cuenta que se asigna una clave API pública a cada usuario de Cloud Manager, pero este puede acceder a varios proyectos.
Ejemplo
Consideremos dos usuarios: A y B.
El usuario A pertenece al proyecto X y el usuario B a los proyectos X y Y.
A las 1:00:00pm, el usuario A realiza 50 solicitudes a un recurso con velocidad limitada en el proyecto X, todas las cuales se completan a las 1:00:20pm.
A las 1:00:30p. m., el usuario B intenta realizar 60 solicitudes a un recurso con velocidad limitada en el proyecto X.
Dado que el usuario A ya agotó 50 solicitudes en el minuto 1:00pm para el proyecto X, las últimas 10 solicitudes que el usuario B intenta realizar son rechazadas. Sin embargo, el usuario B puede realizar solicitudes a un recurso con límite de velocidad en el proyecto Y, ya que cada proyecto mantiene un contador de solicitudes independiente.
A las 1:01pm, las solicitudes al proyecto X pueden continuar, porque el contador de solicitudes utilizado para limitar la velocidad se reinicia cada minuto.
Si excede el límite de velocidad, la API devuelve un 429 Too Many Requests código de respuesta HTTP.
Información Adicional
Consulta Recursos de la API de administración de Cloud Manager para obtener una referencia completa de todos los recursos disponibles en la API pública de Cloud Manager.