DevOps時代のAPI管理

これは、DevOps時代のAPI管理、その課題、およびここLogicMonitorでそれらを解決するためにどのように選択したかについてのXNUMX部構成のシリーズの最初のものです。 パートXNUMXではAPIのバージョン管理について説明し、パートXNUMXではSDKとAPIドキュメントの作成について説明します。

堅牢で信頼性が高く、一貫性のあるAPIを持つことは非常に有益であり、エンタープライズSaaS製品に関してはほとんど要件です。 DevOpsの台頭と継続的デリバリーへの移行に伴い、このようなAPIを維持することは困難な場合があります。

急速に変化する製品機能について話している場合、利用可能なAPI機能との下位互換性などの重要な詳細のバランスを取るのは難しくなります。 より短いAPIリリースサイクルで補うことは、通常、一度に多くのバージョンを維持することを意味し、多くのリソースを消費する可能性があります。 一方、APIリリースサイクルが長くなると、機能が不足しているAPIが存在することになり、APIの価値が低下する可能性があります。 ここLogicMonitorでは、RESTAPIの開発中にこの課題に正面から直面しました。

2016年の終わりに、待望のRESTAPIのリリースを発表しました。 製品が頻繁にリリースされるため、多くの個別のバージョン間でこれらの変更を維持する必要なしに、絶え間ない変更を可能にする柔軟性を提供するバージョン管理計画を立てる必要がありました。 最終的に、次のようにバージョン管理することにしました。

セマンティックバージョニングが使用されますが、リクエストではメジャーバージョンのみが許可されます。
フォローします セマンティックバージョニング 標準。 公開されたAPIバージョンへの変更は常に下位互換性があり、マイナーバージョンとパッチバージョンの増分で追跡され、互換性のないすべての変更は新しいメジャーバージョンで導入されます。

マイナーバージョンとパッチバージョンはリリースノートで呼び出され、APIの変更と追加を簡単に追跡できるようになります。 ただし、APIリクエストでメジャーバージョン番号を指定するだけで済みます。 たとえば、バージョン1を指定するリクエストは、リソースの最新バージョン1を返します。 リクエストでメジャーバージョンのみを許可すると、バージョン番号を変更するためにカスタムスクリプトを更新する必要がある回数が制限されます。

RESTAPIのXNUMXつのバージョンが常にサポートされます。
最新のXNUMXつより古いメジャーバージョンは非推奨になりますが、すぐには削除されません。 一定期間バージョンをサポートするのではなく、一定数のバージョンをサポートすることで、不当な数のバージョンを維持することなく、より頻繁なAPIリリースを簡単に行うことができます。 より頻繁なAPIリリースがあると、APIは新しい製品機能に追いつくことができます。

バージョンは、X-VersionヘッダーまたはURLで指定できます。
ヘッダーとURLでバージョンを許可すると、使用しているリソースのバージョンを簡単に操作でき、必要に応じてXNUMXつのバージョンを同時に使用することもできます。

バージョンは、次のようにX-Versionヘッダーで指定できます。

X-Version:1

または、次のようなURLで:

/santaba/rest/device/devices?v=2

REST APIは、常にデフォルトで最新の公開バージョンになります。
これにより、追加の手順を追加することなく、常に最新バージョンを使用していることを簡単に確認できます。リクエストからバージョンをすべて一緒に省略してください。

プログラムで管理できるLogicMonitor機能のリストを拡張することの明らかな(そしてバージョン管理のおかげで、継続的な)利点は別として、 当社のRESTAPIは、RESTful業界標準に沿ったセキュリティと使いやすさの大幅な改善を提供します。 まだ使用していない場合は、次の理由があります。

LMv1認証:
当社のRESTAPI LMv1認証は、APIトークンの秘密鍵、タイムスタンプ、およびリクエストの詳細に基づいて、base64でエンコードされたHMAC署名を利用します。 これにより、認証情報が十分に暗号化され、リクエストがリプレイ攻撃の影響を受けにくくなります。 さらに、APIトークンを使用すると、APIアクセスとUIアクセスを個別にプロビジョニングおよび取り消すことができ、監査ログ内のユーザーAPIアクションをより明確にすることができます。

成功したすべてのPOST、PUT、PATCH、およびDELETEリクエストは、ユーザー名、APIトークン、およびAPIアクションとともにログに記録されます。
API更新ログ

失敗したAPIリクエストは、ユーザー名、APIトークン、試行されたAPIアクションとともにログに記録されます。
APIGETが失敗する

論理リソース:
私たちのRESTAPIは、RESTful標準に準拠し、LogicMonitor UIに表示されるものに密接にマッピングされるリソースに論理的に分離されているため、直感的で一貫性があり、使いやすいものになっています。

/device/devices
/device/groups/12/devices

結果のフィルタリング:
REST APIには、返された結果のサイズを並べ替え、フィルタリング、操作するために使用できる強力なフィルタリング機能が含まれているため、大量の結果をふるいにかけることなく、探している正確なデータを簡単に取得できます。 たとえば、次のリクエストは、AWS ap-south-2リージョン(ムンバイ)で監視されているすべてのEC1デバイスの表示名、ID、およびカスタムプロパティを返します。

GET
/device/devices?filter=customProperties.name:system.categories,customProperties.value:AWS/EC2,displayName~AP-S1&fields=displayName,id,customProperties

応答:

Response Status: 200
Response Body: {
  "status" : 200,
    "errmsg" : "OK",
    "data" : {
      "total" : 1,
      "items" : [{
        "id" : 535,
        "displayName" : "AP-S1:i-072eed28687366631",
        "customProperties" : [{
          "name" : "system.categories",
          "value" : "AWS/EC2"
        }]
      }],
      "searchId" : null
    }
  }

ご確認ください> RESTAPIドキュメント リソースと利用可能なメソッドの詳細、およびさまざまな言語のスクリプトの例については、こちらをご覧ください。 アカウントのフィードバックボタンから、新しいREST APIに関する質問、提案、フィードバックをお寄せください。 ご意見をお聞かせください。