Lakebase データ API

Important

Lakebase 自動スケールは、、eastus2、westeuropeの各リージョンでwestusになります。

Lakebase 自動スケーリングは、自動スケールコンピューティング、ゼロへのスケーリング、分岐、インスタントリストアを備えた最新バージョンの Lakebase です。 Lakebase Provisioned との機能の比較については、バージョンの選択を参照してください。

Lakebase Data API は PostgREST と互換性のある RESTful インターフェイスであり、標準の HTTP メソッドを使用して Lakebase Postgres データベースと直接対話できます。データベーススキーマから派生した API エンドポイントが提供されるため、カスタムバックエンド開発を必要とせずに、データに対するセキュリティで保護された CRUD (作成、読み取り、更新、削除) 操作が可能になります。

概要

Data API は、データベーススキーマに基づいて RESTful エンドポイントを自動的に生成します。データベース内の各テーブルに HTTP 要求を介してアクセスできるようになり、次の操作が可能になります。

柔軟なフィルター処理、並べ替え、改ページ処理を使用して HTTP 要求を使用してGETする
HTTP POST 要求を使用してレコードを挿入する
HTTP PATCH または PUT 要求を使用してレコードを更新する
HTTP DELETE 要求を使用してレコードを削除する
HTTP POST 要求を使用して関数を RPC として実行する

この方法では、カスタム API コードを記述して維持する必要がなくなり、アプリケーションロジックとデータベーススキーマに集中できます。

PostgREST の互換性

Lakebase Data API は、PostgREST 仕様と互換性があります。次のようにすることができます。

既存の PostgREST クライアントライブラリとツールを使用する
フィルタリング、並べ替え、ページネーションの PostgREST 規則に従う
PostgREST コミュニティのドキュメントと例を調整する

注

Lakebase Data API は、PostgREST 仕様と互換性を持つよう設計された Azure Databricks の実装です。 Data API は独立した実装であるため、Lakebase 環境に適用できない一部の PostgREST 機能は含まれません。機能の互換性の詳細については、「機能互換性リファレンス」を参照してください。

API の機能、クエリパラメーター、および機能の包括的な詳細については、 PostgREST API リファレンスを参照してください。

ユースケース（活用事例）

Lakebase Data API は、次の場合に最適です。

Web アプリケーション: HTTP 要求を介してデータベースと直接やり取りするフロントエンドを構築する
マイクロサービス: REST API を使用してデータベースリソースにアクセスする軽量サービスを作成する
サーバーレスアーキテクチャ: サーバーレス関数とエッジコンピューティングプラットフォームとの統合
モバイルアプリケーション: RESTful インターフェイスを介して直接データベースにアクセスするモバイルアプリを提供する
サードパーティの統合: 外部システムがデータの読み取りと書き込みを安全に行えるようにする

データ API を設定する

このセクションでは、必要なロールの作成から最初の API 要求の作成まで、Data API を設定する手順について説明します。

前提条件

Data API には、Lakebase Postgres 自動スケールデータベースプロジェクトが必要です。お持ちでない場合は、「データベースプロジェクトの概要」を参照してください。

ヒント

Data API をテストするためのサンプルテーブルが必要な場合は、Data API を有効にする前に作成してください。スキーマの完全な例については、サンプルスキーマを参照してください。

データ API を有効にする

Data API は、 authenticatorという名前の単一の Postgres ロールを介してすべてのデータベースアクセスを行います。ログイン以外のアクセス許可は必要ありません。 Lakebase アプリを使用して Data API を有効にすると、このロールと必要なインフラストラクチャが自動的に作成されます。

Data API を有効にする:

プロジェクトの [データ API ] ページに移動します。
[ データ API の有効化] をクリックします。

[データ API の有効化] ボタン

これにより、 authenticator ロールの作成、 pgrst スキーマの構成、API を使用した public スキーマの公開など、すべてのセットアップ手順が自動的に実行されます。

注

( publicを超えて) 追加のスキーマを公開する必要がある場合は、 Advanced Data API 設定で公開されているスキーマを変更できます。

Data API を有効にした後

Data API を有効にした後、Lakebase アプリには、API と設定の 2 つのタブが含まれたデータ API ページが表示されます。

API URL とセキュリティオプションを示すデータ API ページ

[API] タブには、次の情報が表示されます。

API URL: アプリケーションコードと API 要求で使用する REST エンドポイント URL。表示される URL にはスキーマが含まれていないため、API 要求を行うときに、スキーマ名 ( /public など) を URL に追加する必要があります。
スキーマキャッシュの更新: データベーススキーマを変更した後に API のスキーマキャッシュを更新するボタン。スキーマキャッシュの更新を参照してください。
データを保護する: テーブルに対して Postgres 行レベルセキュリティ (RLS) を有効にするオプション。行レベルのセキュリティを有効にするを参照してください。

[ 設定] タブには、公開されたスキーマ、最大行数、CORS 設定など、API の動作を構成するためのオプションが用意されています。詳細なデータ API 設定を参照してください。

サンプルスキーマ (省略可能)

このドキュメントの例では、次のスキーマを使用します。独自のテーブルを作成することも、テストにこのサンプルスキーマを使用することもできます。 Lakebase SQL エディターまたは任意の SQL クライアントを使用して、次の SQL ステートメントを実行します。

-- Create clients table
CREATE TABLE clients (
  id SERIAL PRIMARY KEY,
  name TEXT NOT NULL,
  email TEXT UNIQUE NOT NULL,
  company TEXT,
  phone TEXT,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- Create projects table with foreign key to clients
CREATE TABLE projects (
  id SERIAL PRIMARY KEY,
  name TEXT NOT NULL,
  description TEXT,
  client_id INTEGER NOT NULL REFERENCES clients(id) ON DELETE CASCADE,
  status TEXT DEFAULT 'active',
  start_date DATE,
  end_date DATE,
  budget DECIMAL(10,2),
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- Create tasks table with foreign key to projects
CREATE TABLE tasks (
  id SERIAL PRIMARY KEY,
  title TEXT NOT NULL,
  description TEXT,
  project_id INTEGER NOT NULL REFERENCES projects(id) ON DELETE CASCADE,
  status TEXT DEFAULT 'pending',
  priority TEXT DEFAULT 'medium',
  assigned_to TEXT,
  due_date DATE,
  estimated_hours DECIMAL(5,2),
  actual_hours DECIMAL(5,2),
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- Insert sample data
INSERT INTO clients (name, email, company, phone) VALUES
  ('Acme Corp', 'contact@acme.com', 'Acme Corporation', '+1-555-0101'),
  ('TechStart Inc', 'hello@techstart.com', 'TechStart Inc', '+1-555-0102'),
  ('Global Solutions', 'info@globalsolutions.com', 'Global Solutions Ltd', '+1-555-0103');

INSERT INTO projects (name, description, client_id, status, start_date, end_date, budget) VALUES
  ('Website Redesign', 'Complete overhaul of company website with modern design', 1, 'active', '2024-01-15', '2024-06-30', 25000.00),
  ('Mobile App Development', 'iOS and Android app for customer management', 1, 'planning', '2024-07-01', '2024-12-31', 50000.00),
  ('Database Migration', 'Migrate legacy system to cloud database', 2, 'active', '2024-02-01', '2024-05-31', 15000.00),
  ('API Integration', 'Integrate third-party services with existing platform', 3, 'completed', '2023-11-01', '2024-01-31', 20000.00);

INSERT INTO tasks (title, description, project_id, status, priority, assigned_to, due_date, estimated_hours, actual_hours) VALUES
  ('Design Homepage', 'Create wireframes and mockups for homepage', 1, 'in_progress', 'high', 'Sarah Johnson', '2024-03-15', 16.00, 8.00),
  ('Setup Development Environment', 'Configure local development setup', 1, 'completed', 'medium', 'Mike Chen', '2024-02-01', 4.00, 3.50),
  ('Database Schema Design', 'Design new database structure', 3, 'completed', 'high', 'Alex Rodriguez', '2024-02-15', 20.00, 18.00),
  ('API Authentication', 'Implement OAuth2 authentication flow', 4, 'completed', 'high', 'Lisa Wang', '2024-01-15', 12.00, 10.50),
  ('User Testing', 'Conduct usability testing with target users', 1, 'pending', 'medium', 'Sarah Johnson', '2024-04-01', 8.00, NULL),
  ('Performance Optimization', 'Optimize database queries and caching', 3, 'in_progress', 'medium', 'Alex Rodriguez', '2024-04-30', 24.00, 12.00);

ユーザーのアクセス許可を構成する

Authorization ヘッダーを介して送信される Azure Databricks OAuth ベアラートークンを使用して、すべてのデータ API 要求を認証する必要があります。 Data API は、基になるアクセス許可を管理する Postgres を使用して、認証された Azure Databricks ID へのアクセスを制限します。

authenticator ロールは、API 要求を処理するときに、要求するユーザーの ID を引き受け取ります。これを機能させるには、Data API にアクセスする各 Azure Databricks ID に、データベース内の対応する Postgres ロールが必要です。 Azure Databricks アカウントにユーザーを最初に追加する必要がある場合は、「アカウントにユーザーを追加する」を参照してください。

Postgres ロールを追加する

databricks_auth拡張機能を使用して、Azure Databricks ID に対応する Postgres ロールを作成します。

拡張機能を作成する:

CREATE EXTENSION IF NOT EXISTS databricks_auth;

Postgres ロールを追加します。

SELECT databricks_create_role('user@databricks.com', 'USER');

詳細な手順については、「 SQL を使用して Azure Databricks ID の OAuth ロールを作成する」を参照してください。

Important

データベース所有者アカウント (Lakebase プロジェクトを作成した Azure Databricks ID) を使用して Data API にアクセスしないでください。 authenticator ロールには自身の役割を担う能力が必要であり、高い権限を持つアカウントにはそのアクセス許可を付与できません。

データベース所有者ロールに authenticatorを許可しようとすると、次のエラーが表示されます。

ERROR:  permission denied to grant role "db_owner_user@databricks.com"
DETAIL:  Only roles with the ADMIN option on role "db_owner_user@databricks.com" may grant this role.

ユーザーにアクセス許可を付与する

Azure Databricks ID に対応する Postgres ロールを作成したので、それらの Postgres ロールにアクセス許可を付与する必要があります。これらのアクセス許可は、各ユーザーが API 要求を介して対話できるデータベースオブジェクト (スキーマ、テーブル、シーケンス、関数) を制御します。

標準の SQL GRANT ステートメントを使用してアクセス許可を付与します。この例では、 public スキーマを使用します。別のスキーマを公開する場合は、 public をスキーマ名に置き換えます。

-- Allow authenticator to assume the identity of the user
GRANT "user@databricks.com" TO authenticator;

-- Allow user@databricks.com to access everything in public schema
GRANT USAGE ON SCHEMA public TO "user@databricks.com";
GRANT SELECT, UPDATE, INSERT, DELETE ON ALL TABLES IN SCHEMA public TO "user@databricks.com";
GRANT USAGE ON ALL SEQUENCES IN SCHEMA public TO "user@databricks.com";
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO "user@databricks.com";

この例では、public ID のuser@databricks.com スキーマへのフルアクセスを許可します。これを実際の Azure Databricks ID に置き換え、要件に基づいてアクセス許可を調整します。

Important

行レベルのセキュリティを実装する: 上記のアクセス許可はテーブルレベルのアクセス権を付与しますが、ほとんどの API ユースケースでは行レベルの制限が必要です。たとえば、マルチテナントアプリケーションでは、ユーザーは自分のデータまたは組織のデータのみを表示する必要があります。 PostgreSQL 行レベルセキュリティ (RLS) ポリシーを使用して、データベースレベルできめ細かなアクセス制御を適用します。「行レベルのセキュリティを実装する」を参照してください。

認証

Data API にアクセスするには、HTTP 要求の Authorization ヘッダーに Azure Databricks OAuth トークンを指定する必要があります。認証された Azure Databricks ID には、データベースのアクセス許可を定義する対応する Postgres ロール (前の手順で作成) が必要です。

OAuth トークンを取得する

前の手順で Postgres ロールを作成した Azure Databricks ID としてワークスペースに接続し、OAuth トークンを取得します。手順については、「認証」を参照してください。

要求を行う

OAuth トークンと API URL (Lakebase アプリの [ API ] タブから使用可能) を使用すると、curl または任意の HTTP クライアントを使用して API 要求を行うことができます。スキーマ名 (たとえば、 /public) を API URL に追加することを忘れないでください。次の例では、 DBX_OAUTH_TOKEN と REST_ENDPOINT 環境変数をエクスポートしていることを前提としています。

(サンプルクライアント/プロジェクト/タスクスキーマを使用して) 予想される出力を使用した呼び出しの例を次に示します。

curl -H "Authorization: Bearer $DBX_OAUTH_TOKEN" \
  "$REST_ENDPOINT/public/clients?select=id,name,projects(id,name)&id=gte.2"

応答の例:

[
  { "id": 2, "name": "TechStart Inc", "projects": [{ "id": 3, "name": "Database Migration" }] },
  { "id": 3, "name": "Global Solutions", "projects": [{ "id": 4, "name": "API Integration" }] }
]

API 操作の詳細な例と詳細については、 API リファレンスセクションを参照してください。クエリパラメーターと API 機能の包括的な詳細については、 PostgREST API リファレンスを参照してください。 Lakebase 固有の互換性情報については、 PostgREST の互換性に関する記事を参照してください。

API を広範囲に使用する前に、データを保護するように行レベルのセキュリティを構成します。

データ API の管理

Data API を有効にした後は、Lakebase アプリを使用してスキーマの変更とセキュリティ設定を管理できます。

スキーマキャッシュの更新

データベーススキーマを変更する (テーブル、列、またはその他のスキーマオブジェクトを追加する) 場合は、スキーマキャッシュを更新する必要があります。これにより、変更は Data API を通じてすぐに使用できるようになります。

スキーマキャッシュを更新するには:

プロジェクトの [アプリバックエンド] セクションの [データ API] に移動します。
[ スキーマキャッシュの更新] をクリックします。

データ API には、最新のスキーマの変更が反映されるようになりました。

行レベルのセキュリティを有効にする

Lakebase アプリでは、データベース内のテーブルに対して行レベルセキュリティ (RLS) をすばやく有効にする方法が提供されます。スキーマにテーブルが存在する場合、[ API ] タブには次の情報を示す [ データの保護 ] セクションが表示されます。

RLS が有効なテーブル
RLS が無効になっているテーブル (警告あり)
すべてのテーブルに対して RLS を有効にするための RLS を有効にする ボタン

Important

Lakebase アプリで RLS を有効にすると、テーブルの行レベルのセキュリティが有効になります。 RLS を有効にすると、既定ではすべての行がユーザーにアクセスできなくなります (ただし、テーブル所有者、BYPASSRLS 属性を持つロール、スーパーユーザーは除きますが、スーパーユーザーは Lakebase ではサポートされません)。セキュリティ要件に基づいて特定の行へのアクセスを許可するには、RLS ポリシーを作成する必要があります。ポリシーの作成については、行レベルのセキュリティを参照してください。

テーブルの RLS を有効にするには:

プロジェクトの [アプリバックエンド] セクションの [データ API] に移動します。
[ データの保護 ] セクションで、RLS が有効になっていないテーブルを確認します。
[ RLS を有効にする] をクリックして、すべてのテーブルの行レベルのセキュリティを有効にします。

また、SQL を使用して個々のテーブルに対して RLS を有効にすることもできます。詳細については、行レベルのセキュリティを参照してください。

Advanced Data API の設定

Lakebase アプリの [API] タブの [詳細設定] セクションでは、データ API エンドポイントのセキュリティ、パフォーマンス、および動作が制御されます。

公開されたスキーマ

既定値:public

REST API エンドポイントとして公開される PostgreSQL スキーマを定義します。既定では、 public スキーマにのみアクセスできます。他のスキーマ ( api、 v1 など) を使用する場合は、ドロップダウンリストから選択して追加します。

注

アクセス許可が適用されます。 ここでスキーマを追加するとエンドポイントが公開されますが、API で使用されるデータベースロールには、スキーマに対する USAGE 権限とテーブルに対する SELECT 権限が必要です。

最大行数

デフォルト： 空

1 つの API 応答で返される行数にハード制限を適用します。これにより、大規模なクエリによる誤ったパフォーマンスの低下を防ぐことができます。クライアントは、このしきい値内のデータを取得するために改ページ制限を使用する必要があります。これにより、大規模なデータ転送による予期しないエグレスコストも回避されます。

CORS で許可されるオリジン

既定： 空 (すべての配信元を許可)

ブラウザーを使用して API からデータをフェッチできる Web ドメインを制御します。

空：* (任意のドメイン) を許可します。開発に役立ちます。
生産： 承認されていない Web サイトが API に対してクエリを実行できないように、特定のドメイン (たとえば、 https://myapp.com) を一覧表示します。

OpenAPI の仕様

デフォルト： 無効

自動生成された OpenAPI 3 スキーマを /openapi.jsonで使用できるかどうかを制御します。このスキーマでは、テーブル、列、および REST エンドポイントについて説明します。有効にすると、これを使用して次のことができます。

API ドキュメントの生成 (Swagger UI、Redoc)
型指定されたクライアントライブラリをビルドする (TypeScript、Python、Go)
Postman に API をインポートする
API ゲートウェイやその他の OpenAPI ベースのツールとの統合

サーバータイミングヘッダー

デフォルト： 無効

有効にすると、Data API には各応答に Server-Timing ヘッダーが含まれます。これらのヘッダーは、要求のさまざまな部分の処理にかかった時間 (データベースの実行時間や内部処理時間など) を示します。この情報を使用して、低速なクエリのデバッグ、パフォーマンスの測定、アプリケーションの待機時間の問題のトラブルシューティングを行うことができます。

注

詳細設定を変更したら、[ 保存 ] をクリックして適用します。

行レベルのセキュリティ

行レベルセキュリティ (RLS) ポリシーでは、ユーザーがテーブル内でアクセスできる行を制限することで、きめ細かいアクセス制御が提供されます。

RLS とデータ API の連携方法: ユーザーが API 要求を行うと、 authenticator ロールはそのユーザーの ID を想定します。そのユーザーのロールに対して定義されているすべての RLS ポリシーは、PostgreSQL によって自動的に適用され、アクセスできるデータがフィルター処理されます。これはデータベースレベルで行われるため、アプリケーションコードですべての行に対してクエリを実行しようとしても、データベースはユーザーが表示できる行のみを返します。これにより、アプリケーションコードでフィルター処理ロジックを必要とせずに、多層防御のセキュリティが提供されます。

RLS が API にとって重要な理由: 接続コンテキストを制御する直接データベース接続とは異なり、HTTP API は単一のエンドポイントを介して複数のユーザーにデータベースを公開します。テーブルレベルのアクセス許可のみとは、ユーザーが clients テーブルにアクセスできる場合、フィルター処理を実装しない限り 、すべての クライアントレコードにアクセスできることを意味します。 RLS ポリシーを使用すると、各ユーザーには、承認されたデータのみが自動的に表示されます。

RLS は次の場合に不可欠です。

マルチテナントアプリケーション: さまざまな顧客または組織間でデータを分離する
ユーザー所有データ: ユーザーが自分のレコードにのみアクセスできるようにする
チームベースのアクセス: チームメンバーまたは特定のグループへの可視性を制限する
コンプライアンス要件: データベースレベルでデータアクセス制限を適用する

RLS を有効にする

RLS は、Lakebase アプリまたは SQL ステートメントを使用して有効にすることができます。 Lakebase アプリの使用方法については、「行レベルのセキュリティを有効にする」を参照してください。

Warnung

RLS が有効になっていないテーブルがある場合、Lakebase アプリの [API ] タブには、認証されたユーザーがそれらのテーブルのすべての行を表示できることを示す警告が表示されます。 Data API は Postgres スキーマと直接やり取りします。また、API にはインターネット経由でアクセスできるため、PostgreSQL 行レベルのセキュリティを使用してデータベースレベルでセキュリティを適用することが重要です。

SQL を使用して RLS を有効にするには、次のコマンドを実行します。

ALTER TABLE clients ENABLE ROW LEVEL SECURITY;

RLS ポリシーを作成する

テーブルで RLS を有効にした後、アクセス規則を定義するポリシーを作成する必要があります。ポリシーがないと、ユーザーは行にアクセスできません (既定では、すべての行が非表示になります)。

ポリシーのしくみ: テーブルで RLS が有効になっている場合、ユーザーは少なくとも 1 つのポリシーに一致する行のみを表示できます。他のすべての行はフィルターで除外されます。テーブル所有者、 BYPASSRLS 属性を持つロール、およびスーパーユーザーは行セキュリティシステムをバイパスできます (ただし、Lakebase ではスーパーユーザーはサポートされていません)。

注

Lakebase では、 current_user は認証されたユーザーの電子メールアドレス (たとえば、 user@databricks.com) を返します。 RLS ポリシーでこれを使用して、要求を行っているユーザーを特定します。

基本的なポリシー構文:

CREATE POLICY policy_name ON table_name
  [TO role_name]
  USING (condition);

policy_name: ポリシーのわかりやすい名前
table_name: ポリシーを適用するテーブル
TO role_name: 省略可能。このポリシーのロールを指定します。ポリシーをすべてのロールに適用するには、この句を省略します。
USING (条件):表示される行を決定する条件

RLS チュートリアル

次のチュートリアルでは、このドキュメントのサンプルスキーマ (クライアント、プロジェクト、タスクテーブル) を使用して、行レベルのセキュリティを実装する方法を示します。

シナリオ: 割り当てられたクライアントと関連プロジェクトのみを表示する必要がある複数のユーザーがいます。アクセスを制限して、次の目的が達成されるようにします。

alice@databricks.com ID が 1 と 2 のクライアントのみを表示できます
bob@databricks.com ID が 2 と 3 のクライアントのみを表示できます

手順 1: クライアントテーブルで RLS を有効にする

ALTER TABLE clients ENABLE ROW LEVEL SECURITY;

手順 2: Alice のポリシーを作成する

CREATE POLICY alice_clients ON clients
  TO "alice@databricks.com"
  USING (id IN (1, 2));

手順 3: Bob のポリシーを作成する

CREATE POLICY bob_clients ON clients
  TO "bob@databricks.com"
  USING (id IN (2, 3));

手順 4: ポリシーをテストする

Alice が API 要求を行うとき:

# Alice's token in the Authorization header
curl -H "Authorization: Bearer $ALICE_TOKEN" \
  "$REST_ENDPOINT/public/clients?select=id,name"

応答 (Alice にはクライアント 1 と 2 のみが表示されます):

[
  { "id": 1, "name": "Acme Corp" },
  { "id": 2, "name": "TechStart Inc" }
]

Bob が API 要求を行うとき:

# Bob's token in the Authorization header
curl -H "Authorization: Bearer $BOB_TOKEN" \
  "$REST_ENDPOINT/public/clients?select=id,name"

応答 (Bob にはクライアント 2 と 3 のみが表示されます):

[
  { "id": 2, "name": "TechStart Inc" },
  { "id": 3, "name": "Global Solutions" }
]

一般的な RLS パターン

これらのパターンは、Data API の一般的なセキュリティ要件をカバーしています。

ユーザーの所有権 - 認証されたユーザーに行を制限します。

CREATE POLICY user_owned_data ON tasks
  USING (assigned_to = current_user);

テナントの分離 - 行をユーザーの組織内に制限します。

CREATE POLICY tenant_data ON clients
  USING (tenant_id = (
    SELECT tenant_id
    FROM user_tenants
    WHERE user_email = current_user
  ));

チームメンバーシップ - ユーザーのチームに関連する行を制限します。

CREATE POLICY team_projects ON projects
  USING (client_id IN (
    SELECT client_id
    FROM team_clients
    WHERE team_id IN (
      SELECT team_id
      FROM user_teams
      WHERE user_email = current_user
    )
  ));

ロールベースのアクセス - ロールメンバーシップに基づいて行を制限します。

CREATE POLICY manager_access ON tasks
  USING (
    status = 'pending' OR
    pg_has_role(current_user, 'managers', 'member')
  );

特定のロールには読み取り専用権限 - 操作ごとに異なるポリシーを適用:

-- Allow all users to read their assigned tasks
CREATE POLICY read_assigned_tasks ON tasks
  FOR SELECT
  USING (assigned_to = current_user);

-- Only managers can update tasks
CREATE POLICY update_tasks ON tasks
  FOR UPDATE
  TO "managers"
  USING (true);

その他のリソース

ポリシーの種類、セキュリティのベストプラクティス、高度なパターンなど、RLS の実装に関する包括的な情報については、 PostgreSQL 行セキュリティポリシーのドキュメントを参照してください。

アクセス許可の詳細については、「アクセス許可の管理」を参照してください。

API リファレンス

このセクションでは、セットアップ手順、構成されたアクセス許可、および行レベルのセキュリティの実装が完了していることを前提としています。次のセクションでは、一般的な操作、高度な機能、セキュリティに関する考慮事項、互換性の詳細など、データ API の使用に関するリファレンス情報を提供します。

基本的な操作

レコードをクエリする

HTTP GETを使用してテーブルからレコードを取得します。

curl -H "Authorization: Bearer $DBX_OAUTH_TOKEN" \
  "$REST_ENDPOINT/public/clients"

応答の例:

[
  { "id": 1, "name": "Acme Corp", "email": "contact@acme.com", "company": "Acme Corporation", "phone": "+1-555-0101" },
  {
    "id": 2,
    "name": "TechStart Inc",
    "email": "hello@techstart.com",
    "company": "TechStart Inc",
    "phone": "+1-555-0102"
  }
]

結果のフィルター処理

クエリパラメーターを使用して結果をフィルター処理します。次の例では、2 以上の id を持つクライアントを取得します。

curl -H "Authorization: Bearer $DBX_OAUTH_TOKEN" \
  "$REST_ENDPOINT/public/clients?id=gte.2"

応答の例:

[
  { "id": 2, "name": "TechStart Inc", "email": "hello@techstart.com" },
  { "id": 3, "name": "Global Solutions", "email": "info@globalsolutions.com" }
]

特定の列を選択してテーブルを結合する

select パラメーターを使用して、特定の列を取得し、関連テーブルを結合します。

curl -H "Authorization: Bearer $DBX_OAUTH_TOKEN" \
  "$REST_ENDPOINT/public/clients?select=id,name,projects(id,name)&id=gte.2"

応答の例:

[
  { "id": 2, "name": "TechStart Inc", "projects": [{ "id": 3, "name": "Database Migration" }] },
  { "id": 3, "name": "Global Solutions", "projects": [{ "id": 4, "name": "API Integration" }] }
]

レコードの挿入

HTTP POST を使用して新しいレコードを作成する:

curl -X POST \
  -H "Authorization: Bearer $DBX_OAUTH_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "New Client",
    "email": "newclient@example.com",
    "company": "New Company Inc",
    "phone": "+1-555-0104"
  }' \
  "$REST_ENDPOINT/public/clients"

レコードの更新

HTTP PATCH を使用して既存のレコードを更新する:

curl -X PATCH \
  -H "Authorization: Bearer $DBX_OAUTH_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"phone": "+1-555-0199"}' \
  "$REST_ENDPOINT/public/clients?id=eq.1"

レコードを削除する

HTTP DELETE を使用してレコードを削除する:

curl -X DELETE \
  -H "Authorization: Bearer $DBX_OAUTH_TOKEN" \
  "$REST_ENDPOINT/public/clients?id=eq.5"

高度な機能

改ページ

limitパラメーターとoffset パラメーターを使用して、返されるレコードの数を制御します。

curl -H "Authorization: Bearer $DBX_OAUTH_TOKEN" \
  "$REST_ENDPOINT/public/tasks?limit=10&offset=0"

並べ替え

order パラメーターを使用して結果を並べ替えます。

curl -H "Authorization: Bearer $DBX_OAUTH_TOKEN" \
  "$REST_ENDPOINT/public/tasks?order=due_date.desc"

複雑なフィルター処理

複数のフィルター条件を組み合わせる:

curl -H "Authorization: Bearer $DBX_OAUTH_TOKEN" \
  "$REST_ENDPOINT/public/tasks?status=eq.in_progress&priority=eq.high"

一般的なフィルター演算子:

eq -等しい
gte - 以上または等しい
lte - 以下
neq - 等しくない
like - パターンマッチング
in - リスト内の任意の値と一致します

サポートされているクエリパラメーターと API 機能の詳細については、 PostgREST API リファレンスを参照してください。 Lakebase 固有の互換性情報については、 PostgREST の互換性に関する記事を参照してください。

機能互換性リファレンス

このセクションでは、動作が異なる、または Lakebase Data API でサポートされていない PostgREST 機能の一覧を示します。

認証と承認

特徴	ステータス	詳細
JWT の構成	適用なし	Lakebase Data API は、JWT 認証の代わりに Azure Databricks OAuth トークンを使用します。 JWT 固有の構成オプション (カスタムシークレット、RS256 キー、対象ユーザー検証) は使用できません。

リソースの埋め込み

特徴	ステータス	詳細
計算されたリレーションシップ	サポートされていません	`SETOF`または単一レコードを返すデータベース関数を介して定義されたカスタムリレーションシップはサポートされていません。外部キーリレーションシップのみを埋め込むことができます。
内部結合の埋め込み（`!inner` のヒント）	サポートされていません	子条件に基づいて親行をフィルター処理するために左結合を内部結合に変換する `!inner` ヒントはサポートされていません。例: `?select=,clients!inner()&clients.id=eq.1`

応答形式

特徴	ステータス	詳細
カスタムメディアタイプハンドラ	サポートされていません	PostgreSQL 集計によるカスタム出力形式 (バイナリ形式、XML、プロトコルバッファー) はサポートされていません。
Null値の除去	サポートされていません	JSON 応答から null フィールドを削除する `nulls=stripped` メディア型パラメーターはサポートされていません。例: `Accept: application/vnd.pgrst.object+json;nulls=stripped`
PostGIS GeoJSON	部分的にサポートされています。	PostGIS ジオメトリ列はクエリできますが、 `Accept: application/geo+json` ヘッダーを使用した GeoJSON の自動書式設定は使用できません。

改ページとカウント

特徴	ステータス	詳細
計画された数	サポートされていません	PostgreSQL のクエリプランナーを使用して結果数を見積もる `Prefer: count=planned` オプションはサポートされていません。 `Prefer: count=exact` を代わりに使用します。
推定カウント	サポートされていません	概数に PostgreSQL 統計を使用する `Prefer: count=estimated` オプションはサポートされていません。 `Prefer: count=exact` を代わりに使用します。

要求の基本設定

特徴	ステータス	詳細
タイムゾーンの基本設定	部分的にサポートされています。	タイムゾーンの処理は存在しますが、サーバーのタイムゾーンをオーバーライドするための `Prefer: timezone=America/Los_Angeles` ヘッダーはサポートされていません。サーバーのタイムゾーンを構成するか、データベースレベルのタイムゾーン関数を使用します。
トランザクション制御	サポートされていません	`Prefer: tx=commit`および`Prefer: tx=rollback` ヘッダーによるトランザクション制御はサポートされていません。
ユーザー設定管理モード	サポートされていません	無効な基本設定の処理方法を制御するための `Prefer: handling=strict` と `Prefer: handling=lenient` のオプションはサポートされていません。

Observability

Lakebase Data API には、独自の可観測機能が実装されています。次の PostgREST 観測機能はサポートされていません。

特徴	ステータス	詳細
クエリプランの公開	サポートされていません	パフォーマンス分析のために PostgreSQL `Accept: application/vnd.pgrst.plan+json`出力を公開する EXPLAIN ヘッダーはサポートされていません。
Server-Timing ヘッダー	サポートされていません	要求タイミングの内訳を提供する Server-Timing ヘッダーはサポートされていません。 Lakebase では、独自の可観測性機能が実装されています。
トレースヘッダーの伝達	サポートされていません	分散トレースの XRequest-Id およびカスタムトレースヘッダーの伝達はサポートされていません。 Lakebase では、独自の可観測性機能が実装されています。

詳細な構成

特徴	ステータス	詳細
アプリケーション設定 (GUC)	サポートされていません	PostgreSQL GUC を使用してデータベース関数にカスタム構成値を渡すことはサポートされていません。
リクエスト前の関数	サポートされていません	各要求がサポートされない前に実行するデータベース関数を指定できる `db-pre-request` 構成。

PostgREST 機能の詳細については、 PostgREST のドキュメントを参照してください。

セキュリティに関する考慮事項

Data API は、データベースのセキュリティモデルを複数のレベルで適用します。

認証: すべての要求に有効な OAuth トークン認証が必要
ロールベースのアクセス: データベースレベルのアクセス許可は、ユーザーがアクセスできるテーブルと操作を制御します
行レベルのセキュリティ: RLS ポリシーはきめ細かいアクセス制御を適用し、ユーザーが表示または変更できる特定の行を制限します
ユーザーコンテキスト: API は、認証されたユーザーの ID を前提としており、データベースのアクセス許可とポリシーが正しく適用されていることを確認します

推奨セキュリティプラクティス

運用環境のデプロイの場合:

行レベルのセキュリティを実装する: RLS ポリシーを使用して、行レベルでデータアクセスを制限します。これは、マルチテナントアプリケーションとユーザー所有データで特に重要です。行レベルのセキュリティを参照してください。
最小限のアクセス許可を付与する: 広範なアクセス権を付与するのではなく、特定のテーブルに対してユーザーが必要とするアクセス許可 (SELECT、 INSERT、 UPDATE、 DELETE) のみを付与します。
アプリケーションごとに個別のロールを使用する: 1 つのロールを共有するのではなく、さまざまなアプリケーションまたはサービスに専用のロールを作成します。
アクセスを定期的に監査する: 付与されたアクセス許可と RLS ポリシーを定期的に確認して、セキュリティ要件に一致することを確認します。

ロールとアクセス許可の管理については、以下を参照してください。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-02-07

次の方法で共有

Lakebase データ API

概要

PostgREST の互換性

ユース ケース（活用事例）

データ API を設定する

前提 条件

データ API を有効にする

Data API を有効にした後

サンプル スキーマ (省略可能)

ユーザーのアクセス許可を構成する

Postgres ロールを追加する

ユーザーにアクセス許可を付与する

認証

OAuth トークンを取得する

要求を行う

データ API の管理

スキーマ キャッシュの更新

行レベルのセキュリティを有効にする

Advanced Data API の設定

公開されたスキーマ

最大行数

CORS で許可されるオリジン

OpenAPI の仕様

サーバー タイミング ヘッダー

行レベルのセキュリティ

RLS を有効にする

RLS ポリシーを作成する

RLS チュートリアル

一般的な RLS パターン

その他のリソース

API リファレンス

基本的な操作

レコードをクエリする

結果のフィルター処理

特定の列を選択してテーブルを結合する

レコードの挿入

レコードの更新

レコードを削除する

高度な機能

改ページ

並べ替え

複雑なフィルター処理

機能互換性リファレンス

認証と承認

リソースの埋め込み

応答形式

改ページとカウント

要求の基本設定

Observability

詳細な構成

セキュリティに関する考慮事項

推奨セキュリティ プラクティス

フィードバック

その他のリソース

ユースケース（活用事例）

前提条件

サンプルスキーマ (省略可能)

スキーマキャッシュの更新

サーバータイミングヘッダー

推奨セキュリティプラクティス