このドキュメントは、dRofus REST API を使用して、特定のデータベースからデータを取得するための参考資料を示すものです。データベース管理 REST API については、こちらを参照してください： 管理システム REST API
このAPIは、APIを記述したオープン Open API 仕様を提供しています。また、このAPIを探索し、ブラウザ上で試すことができる
インタラクティブなGUIも用意しています。データベース/プロジェクト特有のプロパティを取得する方法を公開し、
文書化しているため、文書を参照するにはログインする必要があります。下記の認証を参照してください。
...
URL | Swagger Gui | Swagger JSON | Note備考 |
|---|---|---|---|
https://api-no.drofus.com | API documentation and test it in web GUIAPIドキュメントを作成し、Web GUIでテスト | use for db2.nosyko.no projectsのプロジェクトで使用。 | |
https://api-eu.drofus.comAPI documentation and test it in web GUI | |||
https://api-ca.drofus.com | API documentation and test it in web GUIAPIドキュメントを作成し、Web GUIでテスト | ||
https://api-us.drofus.com | API documentation and test it in web GUIAPIドキュメントを作成し、Web GUIでテスト | ||
https://api-au.drofus.com/ | API documentation and test it in web GUIAPIドキュメントを作成し、Web GUIでテスト |
Authentication
Bearer
...
認証
ベアラ
APIは一般的にOAauth2標準のBearerトークンをサポートしています。OAuth2 クライアントの登録プロセスは現在手動で行っています。
必要な情報は support@drofus.com までご連絡ください。ご希望のredirect_uri(s) (and if desired, postおよび必要であればpost_logout_redirect_uri(s)).
For testing purpose, HTTP Basic authentication can also be used. However, it should be avoided for production applications.
API-key
API supports reading data using "API-key". This access mode intended to be used by a person for reading ad-hoc data and/or recurring API-calls such as dashboards, PowerQuery (Excel, PoweBI), etc.
Keys can be generated as described here: Power Query#3.-Credentials/Login A generated key will reflect the logged in user and the project
Remarks using API-key
It only supports reading operations
An API-key is valid for a single project. A user may generate multiple API-keys for accessing different project. Generating API-Key twice for the same project will result in same key.
API-keys belong to a single user and are confidential, thus should not be shared
API-key does not intended to be used for machine-to-machine communication and should not be used as such
Technical description
One should send API-key with each HTTP request as standard Authorization header with Reference schemeをお送りください。
テスト目的では HTTP ベーシック認証も使用できます。ただし、本番アプリケーションでは避ける必要があります。
APIキー
APIは、"API-key "を使用したデータの読み取りをサポートしています。
このアクセス・モードは、ダッシュボード、PowerQuery (Excel, PoweBI)などのアドホック・データ (ad-hoc data) および/または定期的なAPIコール (recurring API-calls)の読み取りに使用されます。
キーは、ここで説明されているように生成することができます： パワー・クエリ#3.-認証情報/ログイン 生成されたキーには、ログインしたユーザーとプロジェクトが反映されます。
APIキーを使用した備考
読み取り操作のみをサポートします
API キーは単一のプロジェクトに有効です。ユーザーは、異なるプロジェクトにアクセスするために複数の API キーを生成できます。
同じプロジェクトで API-Key を二度生成すると、同じキーになります。API キーは単一のユーザーに属し、機密であるため、共有しないでください。
API キーはマシン間通信に使用することを意図しておらず、そのように使用すべきではありません。
テクニカル解説
各 HTTP リクエストでは、標準の Authorization ヘッダとして API-key をReference スキーム (scheme) で送信する必要があります。
Authorization: Reference <API-key>
Note that many clients does not allow setting Authorization headers (for example Excel or pasting URL into browser's address bar), but will prompt for inputting username and password when server sends "Unauthorized" respond. Such prompt will result sending request with Authorization header with Basic scheme. So as a fallback, the application also accepting API-key encoded as Authorization header with Basic scheme, where username is a constant apikey and password is the API-key. The wire format will thus look like the following:多くのクライアントは、認証ヘッダー（Excel やブラウザのアドレス バーへの URL の貼り付けなど）の設定を許可していませんが、サーバーが "Unauthorized" を送信すると
ユーザー名とパスワードの入力を求められることに注意してください。このようなプロンプトは、Basic スキームを使用した認証ヘッダーを使用してリクエストを送信します。
そこでフォールバックとして、アプリケーションも、ベーシック・スキームで認証ヘッダーとしてエンコードされたAPI-keyを受け入れ、
ユーザー名は定数のapikey パスワードはAPI-keyになります。したがって、ワイヤーのフォーマットは以下のようになります：
Authorization: Basic base64urlencode(apikey:<API-key>)
This is just an illustration, we recommend using Reference scheme whenever possible. Using API-key encoded in Basic scheme is unnecessary if clients have full control over request headers.
データベースとprojectIdの提供
All API endpoints should provide database and project number as part of the URL path, for example これはあくまでも例であり、可能な限り参照スキームを使用することを推奨します。
クライアントがリクエストヘッダを完全に制御できるのであれば、ベーシック・スキーム (Basic scheme)でエンコードされたAPI-keyを使う必要はありません。
データベースとプロジェクトIDの提供
すべてのAPIエンドポイントは、URLのパスの一部としてデータベースとプロジェクト番号を提供する必要があります。例えば、https://api-host/api/database/projectId/resources
クエリ
We model our query-syntax on the OData standard, but currently only support a small subset of it.
...
Argument
...
現在、OData 標準のクエリ構文をモデルとしていますが、そのごく一部しかサポートしていません。
引数 | 説明 | Sample | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
$select | A comma-separated list of columns to return. 返す列のカンマ区切りリスト。'id' will always be returnedは常に返されます。 | $select=name,architect_no | ||||||||||||||||||
$orderbyA 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 | ソートする列 (コラム)のカンマ区切りリスト。ソートの方向はascまたはdescで指定することができます。 | $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返される行 (ロウ)を制限するために使用します。 列 (コラム) にはフィルタをかける条件を指定することができます。 操作:
| $filter=created gt '2019-1-1' $filter=name in ('kitchen', 'office') $filter=id in (1001, 1003, 1005) $filter=contains(name,'kitch') | ||||||||||||||||||
$topMax number of rows to return. Default is 10000. If more data is available than is returned, the result will contain a RFC5988 header value | 返す行 (ロウ)の最大数。デフォルトは10000。返されるデータよりも多くのデータが利用可能な場合、 | $top=123 | ||||||||||||||||||
$skipHow | many rows to skip on result-set. Default is 0. Can be combined with $top to implement paging結果セットでスキップする行数。デフォルトは 0。 $top と組み合わせて、ページ分割を行うこともできます。 | $skip=100 |
完全なAPIドキュメント
APIは、Open API (以前はSwaggerとして知られていました) と呼ばれる標準フォーマットで記述されています。
...