.png)
dRofus REST APIについて
本資料は、dRofus REST API を使用して指定されたデータベースのデータを取得するための参考資料です。データベース管理用の REST API については、次を参照してください。管理システムREST API :
このAPIは、APIを記述するOpen API 仕様を提供します。 また、このAPIを探索してブラウザで試すことができるインタラクティブなGUIも用意されています。データベース/プロジェクト固有のプロパティを取得する方法を公開して文書化しているため、ドキュメントを表示するにはログインする必要があります。 以下の認証を参照してください。
フィードバックの提供
APIをどのような用途で使用したいのか、遠慮なくお問い合わせください。
URLS
現在、APIは以下の場所に配備されています。今後も増える予定です。APIドキュメントは、プロジェクト固有のプロパティを公開するため、ログインしてご覧いただく必要があります。dRofusのユーザー名とパスワードで接続する方法は、下記のdRofus REST API#Authentication をご参照ください。
URL | Swagger Gui | Swagger JSON | 備考 |
|---|---|---|---|
use for db2.nosyko.no projects | |||
認証について
ベアラ
APIは通常、OAauth2標準ベアラートークンをサポートしています。 OAuth2クライアントの登録プロセスは現在手動で行われています。support@drofus.com に連絡してください。必要な情報を提供できます。必要なredirect_uri(および、必要に応じてpost_logout_redirect_uri)を送信してください。
テスト目的では HTTP Basic認証 も使用できます。ただし、本番アプリケーションでは使用しないでください。
API-Key
APIは、"API-key "を使用したデータの読み込みをサポートしています。 このアクセスモードは、アドホックなデータの読み取りや、ダッシュボード、PowerQuery (Excel, PowerBI) などの定期的なAPIコールのために、人が使用することを意図しています。
キーは、次のように生成できます : Power Query#3.-Credentials/Login 生成されたキーには、ログインしているユーザーとプロジェクトが反映されます。
API-keyを使用した備考
読み取り操作のみをサポートしています
API-keyは、1つのプロジェクトに対して有効です。ユーザーは、異なるプロジェクトにアクセスするために、複数のAPI-Keyを生成することができます。同じプロジェクトに対して2回API-Keyを生成すると、同じキーが生成されます。
API-keyは1人のユーザーに帰属し、機密であるため、共有してはならない。
API-keyは、機械間の通信に使用することを意図していないため、そのように使用しないでください。
技術的な説明
各 HTTP リクエストで API-key を標準のAuthorization(認証)ヘッダーとして Reference スキームで送信する必要があります。
Authorization: Reference <API-key>
多くのクライアントでは、Authorization(認証)ヘッダーを設定することができませんが (例えば、ExcelやブラウザのアドレスバーにURLを貼り付けるなど)、サーバーから “未認証” 応答があった場合、ユーザー名とパスワードの入力を要求します。このようなプロンプトが表示された場合、BasicスキームのAuthorization(認証)ヘッダーを持つリクエストを送信することになります。そこで予備として、アプリケーションはAPI-keyをAuthorization(認証)ヘッダーとしてBasicスキームでエンコードしたものを受け付けます (ユーザー名は定数apikey パスワードはAPI-key) このように、ワイヤーフォーマットは以下のようになります :
Authorization: Basic base64urlencode(apikey:<API-key>)
これはあくまでも一例です。可能な限りReference(参照)スキームを使用することをお勧めします。 クライアントがリクエストヘッダーを完全に制御できる場合、BasicスキームでエンコードされたAPIキーを使用する必要はありません。
データベースとprojectIdの提供
すべてのAPIエンドポイントは、URLパスの一部としてデータベースとプロジェクト番号を提供する必要があります。例えば、 https://api-host/api/database/projectId/resources
クエリ
クエリ構文はOData 標準に基づいてモデル化されていますが、現在サポートされているのはその一部のみです。
論証 | 説明 | 例 |
|---|---|---|
$select | A comma-separated list of columns to return. 'id' will always be returned | $select=name,architect_no |
$orderby | A comma-separated list of columns to sort by. Sorting direction can be specified using asc or desc. Default is asc. If no orderby is specified, the result is sorted by id | $orderby=name,architect_no desc, |
$filter | Used to restrict which rows are returned. A column can have a criteria to filter by. The value for filter can be quoted to handle embedded spaces and strings. Currently only 'and' can be used to combine multiple filters. Operators:OperatorDescriptionEqEqualsNeNot equalLtLess thanGtGreater thanLeLess than or equalGeGreater than or equalInIs a member ofContainsString contains a sub-string | $filter=created gt '2019-1-1' $filter=name in ('kitchen', 'office') $filter=id in (1001, 1003, 1005) $filter=contains(name,'kitch') |
$top | Max number of rows to return. Default is 10000. If more data is available than is returned, the result will contain a RFC5988 header value | $top=123 |
$skip | How many rows to skip on result-set. Default is 0. Can be combined with $top to implement paging | $skip=100 |
すべてのAPIドキュメント
ApiはOpen API（旧称：Swagger）と呼ばれる標準的なフォーマットで記述されている
当社のAPIの基本的な一般的なドキュメントは、”swagger/default/swagger.json” の下で見つけることができます。
しかし、私たちのデータベースは非常に機密性が高いので、データベース固有のファイルをすべてスキーマに入れたバージョンが “swagger/v1/swagger.json” にありますが、ログオンが必要です。
RFC5988
Rfc5988は、結果セットのページ間をナビゲートするためのインターネット標準です。基本的には以下のようなもので、レスポンスヘッダーに追加データのフルリンクが含まれています :
CODE
|