/search エンドポイントを直接呼び出すこともできます。
検索可能な対象
検索は各リソース種別の名前、説明、その他の識別フィールドに対してマッチングを行います。結果は現在の組織にスコープされ、プロジェクトレベルの権限を尊重します。アクセスできるリソースのみが表示されます。
API 経由で検索を使用する
検索は/search エンドポイントで利用できます。完全なリクエスト/レスポンススキーマについてはAPI リファレンスを参照してください。
典型的なリクエストはクエリ文字列を指定し、リソース種別ごとにグループ化されたマッチを返します:
クエリパラメータ
レスポンス形式
レスポンスには一致したresults、元の query、およびクライアントがページネーション UI を描画できるよう、total、limit、offset のページネーションフィールドが含まれます:
total は、検索対象となったエンティティ種別全体で取得された一致件数を反映します（per_type × 検索対象となったエンティティ種別数で上限が設定されます）。したがって total はデータベース内で実際に一致するレコードの総数ではなく、取得段階での上限値です。たとえばデフォルトの per_type=5 で 14 種別を検索した場合、何千件一致しても total は 70 を超えません。大きな結果セットでは total / limit で正確なページ数を計算しないでください。
ページネーションとフィルタリングの例
セルと材料の一致の 2 ページ目を取得し、種別ごとに最大 10 件返す例。ここでのproject_id は、プロジェクトでフィルタリングされるタイプ（スタディ、パイプライン、最適化）のみを絞り込みます。セルと材料の結果は関係なく返されます:
結果のフィールド
各結果にはentity_type、id、name、および (プロジェクト配下のリソースの場合) project_id が含まれます。ネストされたリソースの結果には、含まれる親リソースを指す parent_id も含まれます。たとえば cell_instance の結果の parent_id は、それが属するセル仕様を指す ID であり、channel の結果の parent_id はその親サイクラーを指す ID です。parent_id を使って親リソースへ遷移したり、直接クエリしたりできます。
サイクラーとチャネルの検索
クエリをハードウェアのみに絞り込むには、entity_types=cycler と entity_types=channel を指定します。どちらもプロジェクトスコープのため、project_id を指定すると 1 つのプロジェクトに結果を絞り込めます:
channel の結果は、parent_id に親サイクラーの cycler_id を持ち、そこから直接サイクラーを取得できます。
検索はサーバー上で Postgres の全文インデックスを使用するため、組織にリソースが多く蓄積されてもクエリは高速に返されます。インデックスは自動的に維持されるため、設定は不要です。