REST API 規則

IBM® UrbanCode Release REST API は、それとの相互作用をより整合性のとれたものにするために一連の規則に従っています。

REST URL

サーバー上の各エレメント・タイプは、複数形を持つ最上位 URL として表記されます。多くの場合、この URL では、キャメル・ケース規則によってフォーマット設定された、UCR ユーザー・インターフェースと同じ用語が使用されます。例えば、change types は URL http://base_url/changeTypes/ で表され、environment reservations は URL http://base_url/environmentReservations/ で表され、applications は URL http://base_url/applications/ で表されます。ここで、base_url は、サーバーのホスト名およびパスです。

必須 HTTP ヘッダー

REST API のほとんどの操作は、JSON フォーマットで入力を受け入れるか、JSON フォーマットで出力を返します (またはその両方)。HTTP 規則に従って、JSON 入力を提供する操作には Content-Type 要求ヘッダーが必要で、JSON 出力を作成する操作には Accept 要求ヘッダーが必要です。メディア・タイプ値は application/json になります。開発者の便宜のために、メディア・タイプが text/html で、任意の値を持つ要求 URL に照会パラメーター json が付加されている場合、リストおよび個別の項目に対する GET メソッド (以下で説明) でも JSON 出力が生成されます。このパラメーターは、Accept ヘッダーを変更するための特別なツールを使用せずに、Web ブラウザーから JSON 出力をレンダリングするのに役立ちます。例えば、すべてのアプリケーションの JSON 出力を表示するには、Web ブラウザーのロケーション・バーに http://base_url/applications/?json と入力します。

id プロパティー

アプリケーションなどのエレメントは、固有 ID (UUID) プロパティーを持っています。これは、JSON ストリングの id プロパティーとして JSON オブジェクト表記に現れます。その UUID によって特定のエレメントを参照することができます。この UUID は、REST API 操作の URL およびエレメントの JSON 表記内などの場所で使用することができます。

基本操作

基本の作成、読み取り、更新、削除の各操作は、共通の REST API 規則に従って提供されます。エレメント・タイプの最上位 URL は、そのタイプの項目のコレクションを表します。そのタイプのすべてのエレメントのリストを JSON オブジェクトの配列としてレンダリングするには、HTTP メソッド GET を適切な HTTP ヘッダー、または json 照会パラメーターと共に使用します。新規エレメントを作成するには、適切なタイプの最上位 URL に HTTP メソッド POST を使用し、要求の本体でエレメントの JSON データを提供します。応答本体には、サーバー生成の id プロパティーを含め、新規エレメントのフル JSON 表記を含めます。また、JSON オブジェクトの配列を提供して、単一要求で複数のエレメントを作成することもできます。この場合、応答本体には、要求に指定されたのと同じ順序で新規エレメントの JSON 配列が含まれます。同様に、エレメントの JSON 配列と共に HTTP PUT メソッドを使用することにより、複数のエレメントのデータを更新することができます。フル JSON エレメントを含むか、エレメントの UUID のみを含む JSON 配列と共に HTTP DELETE メソッドを使用することにより、複数のエレメントを削除することができます。

単一の既存エレメントに対して操作を実行するには、そのエレメントの UUID を、そのタイプの最上位 URL に付加します。例えば、提供されているサンプル・リリースの JSON データにアクセスするには、URL http://base_url/releases/00000000-0000-0000-0000-000000000036/ と共に HTTP メソッド GET を使用します。エレメントのデータを更新するには、HTTP PUT メソッドを使用し、更新された JSON オブジェクトを要求本体に提供します。(この場合、要求 URL 内の UUID は、要求本体内の id プロパティーに優先します。) エレメントを削除するには、HTTP DELETE メソッドを使用します。その場合、要求本体は必要ありません。

出力フォーマット

作成、読み取り、および更新の各操作 (POST、GET、および PUT) を使用する場合、オプションの format 照会パラメーターを含めて、特定のユース・ケース用に JSON 出力を調整することができます。このパラメーターを提供しない場合、またはパラメーターの値が認識されない場合は、デフォルトのフォーマットが使用されます。各エレメント・タイプは、異なるフォーマット・セットをサポートしています。これらのフォーマットは、エレメント・タイプの参照情報と共にリストされています。フォーマットの中には大量の詳細を表示するものもあれば、少量の詳細を表示するものもありますが、その違いは、表示される情報のみであり、値は同じです。

list フォーマットと detail フォーマットは、どのエレメント・タイプにも使用できます。list フォーマットは、項目の表に表示されるような要約情報を提供します。detail フォーマットは、より詳細な情報を提供します。このフォーマットには、しばしば関連エレメントの内容が含まれます。一部のエレメントの場合、これらのフォーマットは全く同じです。さらに、name プロパティーを持つエレメント・タイプは、name フォーマットも持っています。このフォーマットには、id プロパティーと name プロパティーのみが含まれています。これは、名前で選択するために項目リストを表示する際に有用な場合があります。便宜のために、エレメント・タイプの name フォーマットは、タイプの最上位 URL に name を付加することによっても作成できます (例えば、GET http://base_url/applications/name)。

JSON 入力規則

作成操作または更新操作の入力として JSON データを提供する時、REST API は、エレメントへの書き込みが可能なプロパティーのみを考慮します。API は他のすべてのデータを無視します。読み取り専用プロパティー (計算されたカウントや作成日など) は更新されません。API は、認識されないプロパティーを無視します。参照を確立するために使用される id プロパティーを除き、関連エレメントのプロパティーも更新されません。

例えば、リリースを作成するために、以下の JSON 入力を提供すると仮定します。
{
  "name": "New Release",
  "team": { 
    "id": "00000000-0000-0000-0000-000000000206", 
    "name": "Not the actual Team name" },
  "lifecycleModel": "00000000-0000-0000-0000-000000000006",
  "totalChanges": 42,
  "BadProperty": "xxxx"
}
API は、この入力を処理する時、リリースの作成に必要なプロパティーのみを認識します。したがって、認識されないプロパティー BadProperty と計算された値 totalChanges は無視されます。この場合、上記の入力は、以下に示す、よりシンプルな入力と同等です。
{
  "name": "New Release",
  "team": "00000000-0000-0000-0000-000000000206",
  "lifecycleModel": "00000000-0000-0000-0000-000000000006"
}

同様に、既存のエレメントを更新すると、API は、JSON 入力に指定されたプロパティーのみを変更します。API は、省略されたプロパティーは変更しません。プロパティーの値をクリアするには、そのプロパティーに対して、明示的な JSON ヌル値を指定します。

例えば、次の内容の、既存の変更について検討します。
{
  "id": "00000000-0000-0000-0000-123456789000",
  "name": "New Feature",
  "description": "",
  "status": "In Progress",
  "type": {
    "id":"00000000-0000-1201-0000-000000000001", 
    "name":"Feature", 
    "icon":"feature"}
}
以下の入力は、この変更をサンプル・リリースに関連付けますが、その変更の他のどのプロパティーも更新しません。
{
  "id": "00000000-0000-0000-0000-123456789000",
  "release": "00000000-0000-0000-0000-000000000036"
}
この操作を反転し、この変更からサンプル・リリースへの関連をクリアするには、以下の入力を使用することができます。
{
  "id": "00000000-0000-0000-0000-123456789000",
  "release": null
}

参照

多くの場合、エレメントの UUID を含む JSON ストリング、または同じ値の id プロパティーを含む JSON オブジェクトのいずれかによって、単一エレメントを参照することができます。前述のとおり、参照されるエレメントの他のプロパティーはすべて無視されます。例えば、変更をリリースに関連付ける場合、以下のすべての JSON オブジェクトは同等です。
{
  "id": "00000000-0000-0000-0000-123456789000",
  "release": "00000000-0000-0000-0000-000000000036"
}
{
  "id": "00000000-0000-0000-0000-123456789000",
  "release": {"id":"00000000-0000-0000-0000-000000000036"}
}
{
  "id": "00000000-0000-0000-0000-123456789000",
  "release": {
    "id":"00000000-0000-0000-0000-000000000036", 
    "name":"Sample Release"}
}
{
  "id": "00000000-0000-0000-0000-123456789000",
  "release": {
    "id":"00000000-0000-0000-0000-000000000036", 
    "name":"Not the actual Release name"}
}

多値 (コレクション) 参照

関係の中には、複数の値を持つことができるものがあります。例えば、単一リリースを、複数のアプリケーションに関連付けることができます。場合によっては、これらの関係は、関係の単一値サイドを作成または更新した時に更新されません。例えば、リリースを作成する時、applications プロパティーに対して提供される値は効果を持ちません。代わりに、以下に示すように、他の URL を使用してリリースにアプリケーションを追加したり、アプリケーションをリリースから削除したりします。
  • リリースに関連するアプリケーションをリストする: GET /releases/{releaseID}/applications
  • リリースにアプリケーションを追加する: POST /releases/{releaseID}/applications/{applicationID}
  • リリースからアプリケーションを削除する: DELETE /releases/{releaseID}/applications/{applicationID}

ただし、他の場合、特にエレメントに特定の関係が必要な場合は、関係の単一値サイドに対する入力を指定することができます。例えば、1 つのアプリケーションを複数のチームに関連付けることができます。この場合は、アプリケーションを作成する時に、「teams」プロパティーに対して UUID ストリングの JSON 配列を提供することができます。この関係を操作するための特別な URL はありません。

キー値プロパティー

エレメント・タイプの中には、静的に定義されたプロパティーに加え、フリー・フォームのキー値ペアの保管および取得をサポートしているものがあります。このタイプのプロパティーは、しばしば、統合プロバイダーにリンクされているデータを表します。例えば、IBM Rational® Team Concert ワークアイテムを表す変更は、そのワークアイテムの ID を、このキー値ストレージ内にプロパティーとして保管する可能性があります。

キー値プロパティーは、properties プロパティーの下の関連エレメントとして、JSON データで表されます。例えば、以下のコードは、firstsecond、および third という名前の付いた、キー値プロパティーの変更を表しています。
{
  "id": "00000000-0000-0000-0000-123456789000",
  "name": "New Feature",
  "description": "",
  "status": "In Progress",
  "type": {
    "id":"00000000-0000-1201-0000-000000000001", 
    "name":"Feature", 
    "icon":"feature"},
  "properties": { 
    "first":"first value", 
    "second":"second value", 
    "third":"third value"}
}
キーと値は両方とも、JSON ストリングとして表す必要があります。静的に定義されたプロパティーと同様に、入力からキーが省略された場合、更新操作はそれを変更しません。キー値ペアをクリアするには、JSON ヌル値をそのキーに割り当てます。

ページ編集

いくつかのエレメント・タイプでは、最上位 GET 要求は、フル・リストではなく、エレメントのサブセットを提供することができます。このようなエレメントのサブセットの取得は、一般的に「ページ編集」と呼ばれます。その理由は、各要求で単一「ページ」のデータのみのロードが行われるためです。

照会パラメーターまたは HTTP Range ヘッダーのいずれかを使用して、2 つの代替ページング・フォームが使用可能です。

ページ編集に照会パラメーターを使用するには、rowsPerPage 照会パラメーターと pageNumber 照会パラメーターの両方を HTTP GET 要求に指定します。最初のページを取得するには、コード pageNumber=1 を指定します。例えば、最初の 5 つのアプリケーションを取得するには、要求 GET http://base_url/applications/?rowsPerPage=5&pageNumber=1 を使用します。

HTTP Range ヘッダーを使用するには、ゼロ・ベース値と包括的値を指定して、項目範囲の開始値と終了値を指定します。例えば、最初の 5 つのアプリケーションを取得するには、要求 GET http://base_url/applications/ に以下のヘッダーを追加します。
Range: items=0-4
ページ編集の要求方法に関係なく、HTTP 応答は、Content-Range ヘッダーを使用して、取得する実際の範囲と使用可能な項目の総数を指定します。例えば、10 の変更のリストの最初の 5 つの変更を要求した場合、応答には以下のヘッダーが含まれます。
Content-Range: 0-4/10
最初の 5 つの変更を要求し、3 つの変更のみが使用可能な場合、ヘッダーは次のようになります。
Content-Range: 0-2/3

ソート

最上位 GET 操作の結果をソートするには、orderField パラメーターと sortType パラメーターを指定します。orderField パラメーターは、ソートに使用する単一プロパティーの名前を含んでいる必要があります。sortType パラメーターは、昇順でソートするための値 asc か、降順でソートするための値 desc を含んでいる必要があります。

関連エレメントのプロパティーでソートを実行するには、ドット付きパス・フォーマットでプロパティー名を指定します。例えば、関連付けられたリリースに従って変更リストをソートするには、値 release.name を指定します。このパス内のいずれかのプロパティーがヌルの場合、順序付けは不特定なものになります。

ソートに、ページ編集および format のパラメーターを組み合わせて使用することができます。例えば、最初の 5 つの変更を、関連リリースの名前によって昇順でソートして、detail フォーマットで取得するには、以下の要求を使用します。
GET http://base_url/changes/?format=detail&rowsPerPage=5&
  pageNumber=1&orderField=release.name&sortType=asc 
すべてのプロパティーをソートに使用できるわけではありません。特に、項目カウントなどの、要約データを表すプロパティーは、一般にソートには使用できません。

フィルター処理

結果をフィルター処理するには、照会パラメーターを指定します。いくつかの照会パラメーターの名前は、結果のフィルター処理に使用するデータ・プロパティーの名前に基づいています。例えば、次の要求は、指定された日付に作成されたリリースを表示します。
GET http://base_url/releases/
  ?filterFields=dateCreated
  &filterType_dateCreated=gt
  &filterClass_dateCreated=Long
  &filterValue_dateCreated=1421171883574
  &orderField=dateCreated
  &sortType=asc
この例は、以下の照会パラメーターを使用します。
filterFields
このパラメーターは、結果のフィルター処理に使用するフィールドを指定します。前の例で、コード filterFields=dateCreated は、特定の日付によって結果をフィルター処理します。複数のフィールドを使用してフィルター処理を行うには、次の例のように、このパラメーターを繰り返します。
filterFields=dateCreated&filterFields=name
filterType_propertyName
このパラメーターは、指定されたプロパティーに対して実行するフィルター操作のタイプを指定します。 前の例には、プロパティー値 filterType_dateCreated=gt がありました。このコードは、dateCreated プロパティーのフィルターが、指定された日付より大きい値を表示することを指定しています。サポートされるフィルター操作は、likeeq (等しい)、ne (等しくない)、gt (より大)、ge (より大か等しい)、lt (より小)、le (より小か等しい)、nullnotnullrange、および in です。
filterClass_propertyName
このプロパティーは、フィルターに指定するデータ型を指定します。前の例で、日付は UNIX タイム・スタンプ値の長整数 (filterClass_dateCreated=Long) でした。有効なデータ型は BooleanLongStringUUID、および Enum です。
各データ型は特定のフィルター・タイプのセットをサポートします。
  • String: likeeqnegtgeltlenullnotnullrange、および in
  • Long: eqnegtgeltlenullnotnullrange、および in
  • Boolean: eqnenullnotnull
  • UUID: eqnenullnotnull
  • Enum: eqnenullnotnull
filterValue_propertyName
このパラメーターは、結果のフィルター処理に使用する値を指定します。前の例は、UNIX タイム・スタンプ・フォーマットで日付を指定しています。range または in のフィルター・タイプを使用する場合は、このパラメーターを複数回指定して、値の範囲またはセットを定義します。 タイプ null および notnull のフィルターにはパラメーターは必要ありません。

フィードバック