メインコンテンツまでスキップ
に最終更新

レイクベースデータAPI

備考

プレビュー

この機能は次のリージョンでパブリック プレビュー段階にあります: us-east-1 、 us-west-2 、 eu-west-1 。

Lakebase オートスケールは、オートスケール コンピュート、ゼロへのスケール、分岐、即時復元を備えた Lakebase の新しいバージョンです。 Lakebase プロビジョニングとの機能の比較については、 「バージョン間の選択」を参照してください。

Lakebase Data API は、標準の HTTP メソッドを使用して Lakebase Postgres データベースと直接対話できる、PostgREST 互換の RESTful インターフェースです。データベース スキーマから派生した 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 仕様と互換性があるように設計された Databricks の実装です。Data API は独立した実装であるため、Lakebase 環境に適用できない一部の PostgREST 機能は含まれていません。機能の互換性の詳細については、 「機能の互換性リファレンス」を参照してください。

API機能、クエリ、機能の包括的な詳細については、「 PostgREST APIリファレンス」を参照してください。

ユースケース​

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

  • Web アプリケーション : HTTP リクエストを通じてデータベースと直接やり取りするフロントエンドを構築します。
  • マイクロサービス : REST APIs経由でデータベース リソースにアクセスする軽量のサービスを作成します。
  • サーバーレスアーキテクチャ ：サーバーレス機能とエッジコンピューティングプラットフォームとの統合
  • モバイル アプリケーション : RESTful インターフェースを通じてモバイル アプリに直接データベース アクセスを提供します。
  • サードパーティ統合 : 外部システムが安全にデータを読み書きできるようにする

データAPIを設定する​

このセクションでは、必要なロールの作成から最初の API リクエストの作成まで、Data API の設定手順を説明します。

前提条件​

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

ヒント

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

データAPIを有効にする​

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

Data API を有効にするには:

  1. プロジェクトの Data API ページに移動します。
  2. 「データ API を有効にする」 をクリックします。

データAPIを有効にするボタン

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

注記

追加のスキーマ（ public以外）を公開する必要がある場合は、 Advanced Data API 設定で公開されたスキーマを変更できます。

データAPIを有効にした後​

Data API を有効にすると、Lakebase アプリに、 API と 設定の 2 つのタブがある Data API ページが表示されます。

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

API タブには次の機能があります。

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

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

サンプルスキーマ（オプション）​

このドキュメントの例では、次のスキーマを使用します。独自のテーブルを作成することも、このサンプル スキーマをテストに使用することもできます。Lakebase SQL エディターまたは任意の 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);

ユーザー権限を設定する​

すべての Data API 要求は、 Authorizationヘッダー経由で送信される Databricks OAuth ベアラー トークンを使用して認証する必要があります。Data API は認証された Databricks ID へのアクセスを制限し、基礎となる権限は Postgres によって管理されます。

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

Postgresロールを追加する​

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

拡張機能を作成します。

SQL
CREATE EXTENSION IF NOT EXISTS databricks_auth;

Postgres ロールを追加します。

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

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

重要

Data API にアクセスする際に、データベース所有者アカウント (Lakebase プロジェクトを作成した Databricks ID) を使用しないでください。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.

ユーザーに権限を付与する​

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

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

SQL
-- 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";

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

重要

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

認証​

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

OAuthローンを取得する​

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

リクエストを行う​

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

以下に、期待される出力を含む呼び出しの例を示します (サンプルの clients/projects/Task スキーマを使用)。

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

応答例：

JSON
[
  { "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 を通じてすぐに利用できるようになります。

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

  1. プロジェクトの App Backend セクションにある Data API に移動します。
  2. [スキーマ キャッシュの更新] をクリックします。

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

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

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

  • RLS が有効になっているテーブル
  • RLS が無効になっているテーブル（警告あり）
  • すべてのテーブルで RLS を有効にする [RLS を有効にする] ボタン
重要

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

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

  1. プロジェクトの App Backend セクションにある Data API に移動します。
  2. 「 データの保護」 セクションで、RLS が有効になっていないテーブルを確認します。
  3. すべてのテーブルに対して行レベルのセキュリティを有効にするには、 「RLS を有効にする」 をクリックします。

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

高度なデータAPI設定​

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

公開されたスキーマ​

デフォルト： public

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

注記

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

最大行数​

デフォルト: 空

単一の API 応答で返される行数に厳しい制限を適用します。これにより、大規模なクエリによる偶発的なパフォーマンスの低下を防ぐことができます。クライアントは、ページ区切りの制限を使用して、このしきい値内でデータを取得する必要があります。これにより、大規模なデータ転送による予期しない送信コストも防止されます。

CORS 許可されたオリジン​

デフォルト: 空 (すべてのオリジンを許可)

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

  • 空: * (任意のドメイン) を許可します。開発に役立ちます。
  • 本番運用: 許可されていない Web サイトがAPIをクエリしないように、特定のドメイン (例: https://myapp.com ) をリストします。

OpenAPI仕様​

デフォルト: 無効

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

  • APIドキュメントを生成する（Swagger UI、Redoc）
  • 型付きクライアント ライブラリを構築する (TypeScript、Python、Go)
  • APIをPostmanにインポートする
  • APIゲートウェイやその他のOpenAPIベースのツールと統合する

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

デフォルト: 無効

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

注記

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

行レベルのセキュリティ​

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

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

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

RLS は以下にとって不可欠です:

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

RLSを有効にする​

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

警告

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

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

SQL
ALTER TABLE clients ENABLE ROW LEVEL SECURITY;

RLS ポリシーの作成​

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

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

注記

Lakebase では、 current_userは認証されたユーザーの電子メール アドレス (例: user@databricks.com ) を返します。 RLS ポリシーでこれを使用して、どのユーザーがリクエストを行っているかを識別します。

基本的なポリシー構文:

SQL
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 を有効にする

SQL
ALTER TABLE clients ENABLE ROW LEVEL SECURITY;

ステップ 2: アリスのポリシーを作成する

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

ステップ 3: ボブのポリシーを作成する

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

ステップ 4: ポリシーをテストする

Alice が API リクエストを行うと、次のようになります。

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

応答 (アリスはクライアント 1 と 2 のみを参照します):

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

Bob が API リクエストを行うと、次のようになります。

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

応答 (ボブはクライアント 2 と 3 のみを参照します):

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

一般的なRLSパターン​

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

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

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

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

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

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

SQL
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
    )
  ));

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

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

特定のロールに対して読み取り専用 - 操作ごとに異なるポリシー:

SQL
-- 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リファレンス​

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

基本操作​

クエリレコード​

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

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

応答例：

JSON
[
  { "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"
  }
]

結果をフィルタリング​

クエリを使用して結果をフィルタリングします。 この例では、 idが 2 以上のクライアントを取得します。

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

応答例：

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

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

select問題を使用して、特定の列を取得し、関連するテーブルを結合します。

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

応答例：

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

レコードを挿入する​

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

Bash
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 を使用して既存のレコードを更新します。

Bash
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 を使用してレコードを削除します。

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

高度な機能​

ページネーション​

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

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

ソート​

order問題を使用して結果を並べ替えます。

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

複雑なフィルタリング​

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

Bash
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 認証の代わりに Databricks OAuth トークンを使用します。JWT 固有の構成オプション (カスタム シークレット、RS256 キー、オーディエンス検証) は使用できません。

リソースの埋め込み​

機能

ステータス

詳細

コンピュート関係

サポートされていない

SETOFまたは単一のレコードを返すデータベース関数を通じて定義されたカスタム リレーションシップはサポートされていません。埋め込むことができるのは外部キー関係のみです。

内部結合埋め込み（ !innerヒント）

サポートされていない

子の基準に基づいて親行をフィルタリングするために左結合を内部結合に変換する!innerヒントはサポートされていません。例： ?select=*,clients!inner(*)&clients.id=eq.1

応答形式​

機能

ステータス

詳細

カスタムメディアタイプハンドラー

サポートされていない

PostgreSQL 集計によるカスタム出力形式 (バイナリ形式、XML、プロトコル バッファ) はサポートされていません。

ストリップされたヌル

サポートされていない

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オプションはサポートされていません。

可観測性​

Lakebase Data API は独自の監視機能を実装します。次の PostgREST 可観測性機能はサポートされていません。

機能

ステータス

詳細

クエリプランの公開

サポートされていない

パフォーマンス分析用の PostgreSQL EXPLAIN 出力を公開するAccept: application/vnd.pgrst.plan+jsonヘッダーはサポートされていません。

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

サポートされていない

リクエストのタイミングの内訳を提供する Server-Timing ヘッダーはサポートされていません。Lakebase は独自の観測可能性機能を実装しています。

トレースヘッダーの伝播

サポートされていない

分散トレースの X-Request-Id およびカスタム トレース ヘッダーの伝播はサポートされていません。Lakebase は独自の観測可能性機能を実装しています。

高度な設定​

機能

ステータス

詳細

アプリケーション設定（GUC）

サポートされていない

PostgreSQL GUC を介してデータベース関数にカスタム構成値を渡すことはサポートされていません。

事前リクエスト機能

サポートされていない

各リクエストの前に実行するデータベース関数を指定できるdb-pre-request構成はサポートされていません。

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

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

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

  • 認証 : すべてのリクエストには有効なOAuth認証が必要です
  • ロールベースのアクセス : データベースレベルの権限は、ユーザーがアクセスできるテーブルと操作を制御します。
  • 行レベルのセキュリティ : RLS ポリシーはきめ細かなアクセス制御を実施し、ユーザーが表示または変更できる特定の行を制限します。
  • ユーザーコンテキスト : APIは認証されたユーザーのIDを想定し、データベースの権限とポリシーが正しく適用されるようにします。

推奨されるセキュリティ対策​

本番運用デプロイメントの場合:

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

役割と権限の管理については、次を参照してください。