Docs Menu
Docs Home
/ /

Público Principios de laAPI

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.

Ejemplo

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.

Todos los recursos admiten un subconjunto de estos métodos HTTP comunes:

Método
Propósito

GET

Recupera la representación JSON de un recurso.

POST

Cree un nuevo recurso utilizando la representación JSON proporcionada.

PUT

Reemplace un recurso con la representación JSON proporcionada.

PATCH

Actualice los campos especificados en un recurso utilizando la representación JSON proporcionada.

DELETE

Eliminar un recurso.

HEAD

Recupere el encabezado de respuesta sin la representación JSON del recurso.

Todas las entidades se representan en JSON. Se aplican las siguientes reglas para solicitudes y convenciones de respuesta:

Aplicar el encabezado de tipo de contenido correcto
Al enviar JSON al servidor a través POST de o,PUT asegú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 POST PATCH o), 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:

Campo
Definición

date

Segundos desde la Unix epoch

increment

Un 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 }
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 username de 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.

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

rel

Nombre (o tipo) de la relación. Muchos de estos se consideran como Tipos de Relaciones de Extensión y tienen el prefijo http://mms.mongodb.com.

href

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.

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

pageNum

Número de página (basado en 1). El valor predeterminado es 1 si no se especifica.

itemsPerPage

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

totalCount

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 pageNum=6 itemsPerPage=10y, entonces totalCount 57es.

results

Conjunto de resultados, que es una matriz de documentos de entidad.

links

Contiene de una a tres relaciones de enlace:

  • previous para la página anterior de resultados (omitido para la primera página);

  • next para la siguiente página de resultados (omitido para la última página);

  • self para la página actual (siempre presente).

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}

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

status

HTTP status code.

content

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.

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.

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

201

Creado.

Se creó un nuevo recurso. Esta es la respuesta típica a una solicitud POST exitosa.

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 DELETE el recurso raíz.

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.

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

detail

string

Descripción legible por humanos del error de solicitud de API.

error

entero

errorCode

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.

parameters

matriz de cadenas

Lista de parámetros pasados ​​en la solicitud de API.

reason

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.

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.

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./api/public/v1.0/groups/<PROJECT-ID>/ Para estos recursos, la cuenta de servicio debe ser miembro de la organización que aloja el proyecto. De lo contrario, Cloud Manager responde con un 401 error.

Cloud Manager vincula muchos recursos a un proyecto. Muchas URL de recursos de API siguen el formato./api/public/v1.0/groups/<PROJECT-ID>/ Para estos recursos, las claves de API deben pertenecer a la organización que aloja el proyecto. De lo contrario, Cloud Manager responde con un 401 error.

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.

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.

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.

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

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

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

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.

Volver

API

En esta página