パブリック APIプリンシパル
MongoDB Ops ManagerパブリックAPIは、 RESTアーキテクチャの原則に従い、 MongoDB Ops Managerの機能へのプログラムによるアクセスを提供する内部リソースを公開します。
APIには、次の機能があります。
- JSONエンティティ
- すべてのエンティティはJSONで表現されます。
- キーベースのアクセス
- MongoDB OpsAPI に接続する必要がある各MongoDB Ops Manager ユーザーまたはアプリケーションは、MongoDB Ops Manager にアクセスする前にAPI キーを生成する 必要があります。MongoDB Ops Manager
- ダイジェスト認証
- 公開APIキー がネットワーク経由で送信されないようにするには、 API リクエストは HTTP ダイジェスト認証を使用して認証されます。
- ブラウザ可能なインターフェース
- 一貫性のあるリンク メカニズムを使用すると、ルート リソースから開始し、関連するリソースへのリンクを追跡することで、API 全体をブラウザできます。
- ユーザー アクセス制御
各 MongoDB Ops Manager ユーザーのAPI機能は、 MongoDB Ops Manager ロールが付与する権限と一致します。
例
{2API
Project Read Only
ロールを持つユーザーは、MongoDB Ops Manager UI または を通じてそのプロジェクト内のリソースを変更できません。- APIネットワーク アクセス リスト
- は、特定のMongoDB Ops Manager アドレスまたは CIDRAPI アドレスへのIP アクセスを制限するための、ユーザーごとの APIAPIアクセス リスト をサポートしています。MongoDB Ops ManagerAPIアクセス リストが空でない ユーザーの場合、すべてのAPI アクセスはアクセス リスト内のIP アドレスから送信される必要があります。空の API アクセス リストを使用すると、アクセス リストで明示的にアドレスを必要とする IP アドレスを除く、任意の IP アドレスからすべての API エンドポイントへのアクセスが許可されます。
HTTPメソッド
すべてのリソースは、次の一般的なHTTPメソッドのサブセットをサポートしています。
方式 | 目的 |
---|---|
GET | リソースのJSON表現を取得します。 |
POST | 指定されたJSON表現を使用して新しいリソースを作成します。 |
PUT | リソースを指定されたJSON表現で置き換えます。 |
PATCH | 提供されたJSON表現を使用して、リソース内の指定されたフィールドを更新します。 |
DELETE | リソースを削除します。 |
HEAD | リソースのJSON表現なしでレスポンスヘッダーを取得します。 |
JSON
すべてのエンティティはJSONで表されます。 リクエストと応答の規則には次のルールが適用されます。
リクエストルール
- 正しいコンテンツタイプヘッダーの適用
POST
またはPUT
を介してサーバーにJSONを送信する場合は、必ず正しいコンテンツタイプのリクエスト ヘッダーを指定してください。Content-Type: application/json
- 日付を ISO として設定8601 String
サーバーに日付を送信する場合(
POST
または リクエスト エンティティのクエリPATCH
パラメータまたはフィールドとして)は、 に準拠した日付を使用します: 8601標準。タイムゾーンを指定しない場合、MongoDB Ops Manager はUTCを想定します。 あいまいさを避けるために、タイムゾーン指定子を含めます。例
2018 年 9 月 27 日は
2018-09-27
として表されます。2018 年 9 月 27 日、午前 4 時 00分 EDT は(タイムゾーンとともに)
2018-09-27T16:00-04:00
として表されます。
場合によっては、タイムスタンプが BSON タイムスタンプ の JSON 表現として返されます 、特にバックアップ リソースがバックアップ リソースに含まれます。BSONタイムスタンプのこの表現は、2 つのフィールドを持つオブジェクトとしてJSON document を提供します。
フィールド定義date
UNIXエポック からの秒数increment
特定の秒内の操作の増分 32 ビット整数序数。例
2018 年 9 月 27 日、午前 4:00、EDT の 3 回目の操作は、次のように表されます(タイムゾーン)
{ date: 2018-09-27T16:00-04:00, increment: 3 }
応答規則
- 無効なフィールドを拒否
無効なフィールドは無視されるのではなく拒否されます。
例
新しいエンティティを作成し、フィールドのいずれかのスペルをうっかり間違えた場合、または既存のエンティティを更新して変更できないフィールドを含めようとすると、 MongoDB Ops ManagerはHTTP 400 ステータス コードと、どのフィールドを示すエラー メッセージを返します。は無効でした。
- 日付を ISO8601 として返します String
- すべての日付は ISO8601 として返されます。 UTC で指定された 形式の文字列 。
- 単位を曖昧にするフィールドにラベルを付ける
特定の単位の数値を含むフィールドには、使用される単位を明確に区別するために名前が付けられます。
例
ホストのアップタイムはミリ秒単位で返されるため、ホスト エンティティ フィールドの名前は
uptimeMsec
です。- 他の値がないフィールドのデフォルト値を返します
現在の値がないフィールドは、適切なデフォルト値とともに返されます。
例
MongoDB Ops Manager には新しく検出されたホストの統計がないため、統計関連のフィールドの値はゼロになります。
認識可能なデフォルト値を持たないフィールドは、エンティティから省略されます。
例
認証を使用していないホストでは、返されるエンティティから
username
フィールドが省略されます。- アルファベット順のフィールドを返します
- JSONMongoDB Ops Managerアプリケーションが返す ドキュメント内のフィールドはアルファベット順です。順序が変更される可能性があります。 フィールドの順序に依存しないでください。
リンク
各リソースには、サブリソースや関連リソースへの 1 つ以上のリンクが含まれています。
例
ホストには、属するプロジェクト、属するレプリカセットなどへのリンクがあります。
リンクは、リンク関係オブジェクトの配列であるエンティティのlinks
フィールドに配置されます。 各リンク関係には 2 つのフィールドがあります。
フィールド | 定義 |
---|---|
rel | 関係の名前(またはタイプ)。 これらの多くは拡張関係タイプと見なされ、 http://mms.mongodb.com というプレフィックスが付きます。 |
href | ターゲットURL 。 |
すべてのエンティティには、 self
と呼ばれるリンク関係が少なくとも 1 つ含まれます。これはつまり、独自のURLです。 エンティティがリストの一部である場合(つまり、プロジェクト内のすべてのホストをリクエストする場合)、そのエンティティにはself
リンク関係のみが含まれます。
例
これは、いくつかのリンクを含むhost
リソースの一部です。
1 { 2 "rel": "http://mms.mongodb.com/project", 3 "href": "https://cloud.mongodb.com/api/public/v1.0/projects/xxx" 4 "id": "xxx", 5 "projectId": "yyy", 6 "hostname": "mongodb.example.com", 7 "port": 27017, 8 "links": [ 9 { 10 "rel": "self", 11 "href": "https://<ops-manager-host>/api/public/v1.0/projects/xxx/hosts/yyy" 12 }, 13 { 14 "rel": "http://mms.mongodb.com/project", 15 "href": "https://<ops-manager-host>/api/public/v1.0/projects/xxx" 16 } 17 ] 18 }
詳細については、「 Web リンク仕様 」を参照してください。 。
注意
Web リンク仕様です が で HTTP レスポンス ヘッダーにリンクを含めるための形式が記述されていますが、これは必須ではありません。APIを簡単に閲覧できるようにするには、レスポンス ヘッダーではなくレスポンス本体にリンクを含めます。
リスト
一部のリソースはエンティティのリストを返します。
例
プロジェクト内のすべてのホストのリストをリクエストできます。
応答でエンティティのリストが要求される場合、結果は 2 つのクエリ パラメータに囲まれたバッチで返されます。
フィールド | 定義 |
---|---|
pageNum | ページ番号(1 から始まる)。 指定しない場合、デフォルトは 1 です。 |
itemsPerPage | 1 ページあたりに返す項目の数は最大 500 です。 指定しない場合、デフォルトは 100 です。 |
応答エンティティには、次の 3 つのフィールドが含まれています。
フィールド | 定義 |
---|---|
totalCount | 結果セット全体内の項目の合計数。 たとえば、プロジェクトに合計57のホストがあり、 |
results | 結果セット 。これはエンティティ ドキュメントの配列です。 |
links | 1 から 3 のリンク関係が含まれています。
|
エンティティのリストのリクエストを行って結果がない場合、 APIはHTTP 200 ステータス コードと空のresults
配列で応答します。 この場合、エンティティのリストが将来のある時点で空ではなくなる可能性があるため、この場合は 404 では応答しません。
存在しないコンテキストでエンティティのリスト(つまり、存在しないプロジェクトのホストのリスト)を要求した場合は、 HTTP 404 応答ステータスが返されます。
例
これは、合計 57 ホストを持つプロジェクト内の 10 個のホストの 2 ページのHTTP応答です。
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 }
エンベロープ
一部のクライアントは、 HTTPレスポンス ヘッダーやステータス コードにアクセスできない場合があります。 この場合は、応答にenvelope
を含めることをリクエストできます。これは、通常応答 ヘッダーに含まれる関連詳細を含む、 JSONドキュメント内の追加の情報レイヤーです。
デフォルトでは、 APIのエンベロープに応答は含まれません。 リクエストするには、クエリ パラメータenvelope=true
を追加します。
単一のエンティティを含む応答の場合、エンベロープには 2 つのフィールドが含まれます。
フィールド | 定義 |
---|---|
status | HTTP status code. |
content | 要求されたエンティティ。 |
エンティティのリストを含む応答の場合、結果をラップするエンベロープはすでにあるため、この場合はクエリ パラメータとしてenvelope=true
を指定すると、既存のエンベロープにstatus
フィールドのみが追加されます。
Pretty Printing(整形表示)
デフォルトでは、MongoDB Ops Manager が返すJSONから余計な空白が削除されます。 pretty-printed JSONをリクエストするには、リクエストにpretty=true
クエリ パラメータを追加します。
curl --user '{USERNAME}:{APIKEY}' --digest \ --header 'Accept: application/json' \ --include \ --request GET "{opsManagerHost}:{Port}/api/public/v1.0?pretty=true"
注意
このドキュメントのすべての例は、わかりやすくするためにpretty-printed JSONを示していますが、一部のサンプルURLにはこの追加のクエリパラメータが含まれていない場合があります。
応答コード
応答では、次のような標準のHTTP応答コードが使用されます。
コード | 意味 | ノート |
---|---|---|
200 | OK | リクエストは成功しました。 これは、 GET リクエストが成功した場合の一般的な応答です。 |
201 | 作成済み | 新しいリソースが作成されました。 これは、 POST リクエストが成功した場合の一般的な応答です。 |
202 | 承認済み | 非同期操作のリクエストが受け入れられました。 |
400 | 無効なリクエスト | クライアント リクエストで問題が発生しました。 |
401 | 許可されていない | 認証は必要ですが、リクエストに含まれていませんでした。 Typically this means that the digest authentication information was omitted from the request, the provided credentials are incorrect, or the user associated with the given API key is not allowed to access the requested resource. |
403 | Forbidden | 指定されたリソースへのアクセスは許可されていません。 |
404 | 見つかりません | 要求されたリソースが存在しない。 |
405 | メソッドは許可されていません | HTTPメソッドは指定されたリソースではサポートされていません。 各リソースがサポートするのはHTTPメソッドのサブセットのみであることに注意してください。 たとえば、ルートリソースを |
409 | 競合 | これは通常、そのプロパティの同じ値を持つ既存のエンティティがすでに存在する場合に一意なエンティティのプロパティを作成または変更するためのリクエストに対する応答です。 たとえば、既存のプロジェクトと同じ名前のプロジェクトを作成しようとすると、リクエストは失敗します。 |
5x | さまざまなサーバーエラー | 予期しない問題が発生しました。 後でもう一度試し、 MongoDB Ops Managerサポートに通知することを検討してください。 |
Errors
リクエストの結果としてエラーが発生した場合、レスポンス本文には、何が起こるかを示す追加の詳細が記載されたJSONドキュメントが含まれます。 ドキュメントには、次の 5 つのフィールドが含まれています。
フィールド | データ型 | 定義 |
---|---|---|
detail | string | APIリクエスト エラーの、人間が判読可能な説明。 |
error | integer | HTTP ステータス コード。 |
errorCode | string | MongoDB Ops ManagerAdministrationAPI エラー コード に示される、API リクエスト エラーを表す名前付き定数。 |
parameters | 文字列の配列 | APIリクエストで渡されるパラメータのリスト。 |
reason | string | HTTP ステータス コードの定義。 |
例
MongoDB Ops Manager は、誤った形式のリクエストに対して次のレスポンス本体を返します。
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 }
コードのリストを確認するには、「 MongoDB Ops Manager Administration APIエラー コード 」を参照してください。
認証
前述のように、 MongoDB Ops Manager APIはHTTPダイジェスト認証を使用します。 ダイジェスト認証の詳細は、このドキュメントの範囲外ですが、基本的にはnoanceと呼ばれるサーバーが生成した一意の値を使用してハッシュされたユーザー名とパスワードが必要です。 ユーザー名は登録された MongoDB Ops Manager アカウントのユーザー名であり、パスワードはそのアカウントに関連付けられた公開APIキーです。
次の点に注意してください。
サーバーが生成した noth は、リクエストを認証するためにサーバーに送り返す前にユーザー名とパスワードをハッシュするために使用されます。 noth は、 ダイジェスト認証の仕様に従って短時間のみ有効です。 これはリプレイ攻撃を防ぐためのもので、期間をキャッシュして永久に使用することはできません。
一部のリソース メソッドはさらに多くのセキュリティを必要とし、リストされている IP アドレスからのみリソースへのアクセスを許可する アクセス リスト によって追加で保護されています。各ユーザーは、リソースへのアクセスを許可するIPアドレスの独自のアクセス リストを構成します。
MongoDB Ops Manager アプリケーションにはロールという概念があり、これによりユーザーが実行できる操作をよりきめ細かく制御できます。API リソースも同じ承認ルールを適用するため、API キーでアクセスできるリソースとメソッドは、関連付けられたユーザーに付与されたロールによって管理されます。
例
ホストを
DELETE
するには、リクエストの実行に使用されるAPIキーを所有するユーザーが、ホストが属するプロジェクトのProject Monitoring Admin
またはProject Owner
である必要があります。次の形式の URL が示すように、多くのリソースがプロジェクト(以前は グループ と呼ばれる)に関連付けられています。
/api/public/v1.0/groups/{PROJECT-ID}/ これらのリソースでは、 APIキーに関連付けられたユーザーはプロジェクトのメンバーであるか、
GLOBAL
ロールのいずれかに割り当てられている必要があります。 それ以外の場合、 MongoDB Ops ManagerアプリケーションはHTTP 401 エラーで応答します。
オートメーション
オートメーション構成リソースと最新プランのオートメーションステータスの取得リソースは、プロジェクトの配置を変更し、配置ステータスを取得するためのエンドポイントを提供します。 新しいオートメーション構成をMongoDB Ops Managerに送信することで配置を変更できます。 オートメーション構成では、配置する MongoDB プロセスを説明して構成します。 MongoDB Ops Managerでは、これを配置の「ターゲット 状態」と指します。 APIを通じて新しいオートメーション構成を送信すると、オートメーションはシステムの現在の状態を目的の状態に一致するように調整します。
重要
APIには、同時変更を防ぐための保護はありません。 2 人の管理者がそれぞれ現在のバージョンに基づく構成で開始し、独自の変更を加えてから変更を送信すると、後の変更が成功します。
詳細情報
のパブリック で利用可能なすべてのリソースの完全なリファレンスについては、「MongoDB Ops Manager AdministrationAPI リソースMongoDB Ops Manager API」を参照してください。