Oracle REST Data Servicesインストールに含まれるNoSQLのサンプル・ファイルも参照してください。NoSQLストアへのアクセスを開始する方法についての簡潔なドキュメントは、Oracle REST Data Servicesをインストールした場所にあるexamples/getting-started-nosql/index.htmlファイルをダブルクリックして参照してください。
トピック:
Oracle REST Data Servicesでは、NoSQLデータおよびメタデータの操作を通じて、Oracle NoSQL DatabaseにアクセスするHTTPベースのRESTサービスを提供できます。データ・アクセスは、NoSQL表へのCRUD(作成、読取り、更新、削除)操作から構成されます。
作成: HTTPのPOSTおよびPUTにより、行データを作成するサービスが提供されます。
読取り: HTTPのGETにより、一貫性および順序についてのディレクティブとともに、行データのキー、部分キーおよびフィールドの範囲参照が提供されます。
更新: HTTPのPUTにより、行データを更新するサービスが提供されます。
削除: HTTPのDELETEにより、行データを削除するサービスが提供されます。
メタデータ・アクセスはHTTPのGETで構成され、NoSQLのメタデータを読み取るサービスが提供されます。
トピック:
NoSQLでOracle REST Data Servicesを使用するためのテクノロジ環境における重要な要素は次のものです。
RESTサービス
Webサービスの呼出しをOracle NoSQL Databaseに向け、マーシャル・データがJSON形式で戻されます。
Oracle WebLogic Server、GlassFishまたはApache Tomcatを使用してデプロイできます。
Oracle NoSQL Database(リリース3.2.5以上)
単一およびマスター/レプリケート・ノードにアクセスする完全なCRUD(作成、読取り、更新、削除)操作が提供されます。
Oracle NoSQL Databaseドライバ(.jarファイル)を介したアクセスが提供されます。
この環境の必須コンポーネントは次のものです。
Java、JavaScript、C++などのクライアント
スタンドアローン(Jetty)、Oracle WebLogic Server、GlassFish、Apache TomcatなどのWebアプリケーション・サーバー
Oracle REST Data Services: HTTPベースのRESTサービス・プロバイダ
NoSQLサーブレット: NoSQLデータベースのCRUD操作を提供するOracle REST Data Servicesコンポーネント
Oracle NoSQL Database: NoSQLサーブレットのターゲットとなる分散型のマスター/レプリカのNoSQLデータベース
次の図で、NoSQLを使用したOracle REST Data Servicesの標準的な環境の概要を示します。
次に、この図の意味を説明します。
Oracle REST Data Servicesは、Webサーバー内にデプロイされます。
クライアントは、Webサーバー内のOracle REST Data ServicesにHTTPリクエストを送信し、レスポンスを受信します。この場合、HTTPリクエストはNoSQLストアのDB1およびDB2をターゲットにしています。
Oracle REST Data Servicesのユーザーおよびロールは、Oracle REST Data Servicesによって使用されます。
2つのNoSQLストア(DB1およびDB2という名前)は、Webサーバー内のOracle REST Data Servicesと通信します。
2のNoSQLストアの構成情報は、Oracle REST Data Servicesによって使用されます。DB1ストアはセキュアであり(NoSQLユーザー、ロールおよびSSL詳細が含まれる)、DB2ストアは非セキュアです。構成情報には、ストアがOracle REST Data Servicesに登録されていることが指定済です。
例5-1は、NoSQLデータベースから表についてのメタデータを取得するRESTサービスのリクエスト(入力)です。
例5-1 NoSQLデータベースからのメタデータの取得
http://localhost:8080/ords/sales/metadata-catalog/
例5-1の内容は次のとおりです。
http://localhost:8080/ordsは、localhostで実行中のWebサーバーからOracle REST Data ServicesのWebアプリケーションにポート8080でアクセスするためのURLです。
/salesは、NoSQLデータベースの識別子です。この識別子は、NoSQL構成にマッピングされます。
metadata-catalog/は、メタデータ・リクエストを処理するコンポーネントです。
例5-1では、レスポンスとして次のような出力が生成されます。
{
"items": [
{
"name": "complexUsers",
"links": [
{
"rel": "canonical",
"href": "http://localhost:8080/ords/sales/metadata-catalog/tables/complexUsers/",
"mediaType": "application/json"
},
{
"rel": "describes",
"href": "http://localhost:8080/ords/sales/tables/complexUsers/"
}
]
},
{
"name": "evolveUsers",
"links": [
{
"rel": "canonical",
"href": "http://localhost:8080/ords/sales/metadata-catalog/tables/evolveUsers/",
"mediaType": "application/json"
},
{
"rel": "describes",
"href": "http://localhost:8080/ords/sales/tables/evolveUsers/"
.
.
.
NoSQLストアのインストールおよび登録には、NoSQLのクライアントとしてのOracle REST Data Servicesインストールのホストが含まれます。そのため、NoSQLストアがセキュアである場合には、セキュリティ・プロパティ・ファイル(client.security)およびSSL情報ファイル(client.trust)をOracle REST Data Servicesのホストのネットワークにコピーする必要があります。これらのファイルは、NoSQLストアが最初に確立されたときに生成されます。NoSQLのドキュメントを参照してください。
NoSQLストアがセキュアな場合、NoSQLのユーザーでアクセスする必要があります。NoSQLでは、パスワード情報を保持するためのウォレット(エンタープライズ・エディション)およびパスワード・ファイル(コミュニティ・エディション)が提供されます。パスワード・ファイルはプレーン・テキストであり、セキュアではないため、Oracle REST Data Servicesではパスワード用に別の記憶域が提供されます。ウォレットの作成もまたNoSQLのドキュメントで説明されており、ウォレットを使用する場合は、それもOracle REST Data Servicesのホストのネットワークにコピーする必要があります。
各Oracle REST Data Servicesインストールには構成ディレクトリがあり、そこにはNoSQLストア構成用のnosqlディレクトリがあります。nosqlディレクトリには、各NoSQLストア用のディレクトリが1つずつあり、各ストア固有のディレクトリには次のファイルが含まれています。
client.security (for Secure noSQL stores) client.trust (for Secure NoSQL stores) Wallet directory (Optional for NoSQL secure stores) nosql.properties
nosql.propertiesファイルには次のものが含まれます。
oracle.dbtools.kv.store.name=<storename> oracle.dbtools.kv.store.hosts=<comma separated set of HOSTS:PORTS> [And optionally the following:] oracle.dbtools.kv.store.pagelimit=<maximum number of items per page> oracle.dbtools.kv.store.security.properties=client.security (the name of the NoSQL client.security file) oracle.dbtools.kv.store.requiredRoles=<list of comma separated roles>
nosql.propertiesファイルにoracle.dbtools.kv.store.requiredRolesプロパティがない場合、RESTサービスは匿名ユーザーに対して許可されており、そうでない場合は、定義されているロールのいずれかを持つユーザーにアクセス権が付与されます。
client.securityファイルにはSSLのプロパティが含まれており、次のプロパティも含まれています。
oracle.kv.auth.username=<NoSQL user used for ORDS to access the store>
client.securityファイルにはまた、次のプロパティが必要になることがあります。
oracle.kv.auth.wallet.dir=<wallet directory>には、ウォレットを使用する場合にウォレットのディレクトリを指定します。
oracle.dbtools.kv.store.auth.pwd=<encrypted pwd>には、パスワード・オプションを使用する場合にNoSQLユーザーのパスワードを指定します。
client.securityファイル内のすべてのパス名はフル・パスで指定する必要があることに注意してください。
後述の例は、次のソートを示しています。
Oracle REST Data Servicesの匿名ユーザーがlocalhostのポート5000でkvstoreという名前でアクセスするストア(標準的なKVLiteストア)は次のようになります。
ords/nosql/sales nosql.properties oracle.dbtools.kv.store.name=kvstore oracle.dbtools.kv.store.hosts=localhost:5000
Oracle REST Data ServicesのSALESロールを持つユーザーがlocalhostのポート5000でkvstoreという名前でアクセスするストア(標準的なKVLiteストア)は次のようになります。
ords/nosql/sales nosql.properties oracle.dbtools.kv.store.name=kvstore oracle.dbtools.kv.store.hosts=localhost:5000 oracle.dbtools.kv.store.requiredRoles=SALES
xyz6160769のポート5000で、パスワードがウォレットに保存されているNOSQL_PUBLIC_USERユーザーがアクセスするセキュア・ストアは、次のようになります。匿名のOracle REST Data Servicesユーザーはアクセスできます。
ords/nosql/sales nosql.properties oracle.dbtools.kv.store.name=mystore oracle.dbtools.kv.store.hosts=xyz6160769.example.com:5000 oracle.dbtools.kv.store.security.properties=client.security client.security oracle.kv.ssl.trustStore=d:/nosqlconfs/ords/nosql/salesecure/client.trust oracle.kv.transport=ssl oracle.kv.ssl.protocols=TLSv1.2,TLSv1.1,TLSv1 oracle.kv.ssl.hostnameVerifier=dnmatch(CN\=NoSQL) oracle.kv.auth.username=NOSQL_PUBLIC_USER oracle.kv.auth.wallet.dir=d:/nosqlconfs/ords/nosql/salesecure/wallet client.trust wallet (directory)
xyz6160769のポート5000で、パスワードがプロパティ・ファイル(エンコード形式)に保存されているNOSQL_PUBLIC_USERユーザーがアクセスするセキュア・ストアは、次のようになります。匿名のOracle REST Data Servicesユーザーはアクセスできます。
ords/nosql/sales nosql.properties oracle.dbtools.kv.store.name=mystore oracle.dbtools.kv.store.hosts=xyz6160769.example.com:5000 oracle.dbtools.kv.store.security.properties=client.security client.security oracle.kv.ssl.trustStore=d:/nosqlconfs/ords/nosql/salesecure/client.trust oracle.kv.transport=ssl oracle.kv.ssl.protocols=TLSv1.2,TLSv1.1,TLSv1 oracle.kv.ssl.hostnameVerifier=dnmatch(CN\=NoSQL) oracle.kv.auth.username=NOSQL_PUBLIC_USER oracle.dbtools.kv.store.auth.pwd=0571B5B831C9945D167D2510B5E6BB021B client.trust
NoSQLストアを追加するには、nosqladdキーワードとともにjavaコマンドを使用します。
使用方法:
java -jar ords.war nosqladd [--secure] [--clientTrustFile] [--clientSecurityFile] [--walletDir] [--password] [--user] [--pagelimit] <storeAlias> <storeName> <hostPorts> <roles>
オプション:
[--secure] ストアがセキュアであることを示すフラグ。
[--clientTrustFile] client.trustファイルの場所(このファイルは、ここからNoSQLの構成領域にコピーされます)。
[--clientSecurityFile] client.securityファイルの場所(このファイルは、将来のアップデートでここからNoSQLの構成領域にコピーされます)。
[--walletDir] ウォレットのディレクトリ(フォルダ)の場所(このディレクトリは、ここからNoSQLの構成領域にコピーされます)。
[--password] 接続のためのパスワード。
[--user] 接続のためのユーザー名。
[-- pagelimit] このストアのページごとの項目の最大数。
引数:
<storeAlias> ストアの別名。
<storeName> ストア名。
<hostPorts> ホスト:ポートの値(カンマ区切りのリスト)。
<roles> ロール(カンマ区切りのリスト)。
NoSQLストアを削除(delete)するには、nosqldelキーワードとともにjavaコマンドを使用します。
使用方法:
java -jar ords.war nosqldel <storeAlias>
引数:
<storeAlias> ストアの別名。
NoSQLリクエストのフォーマットは、次のようになります。
host:port/ords/<nosqlalias>/<nosqlservice>
説明:
<nosqlalias>は、NoSQLストアの別名です。
<nosqlservice>は、呼び出されるメタデータ、データ、またはDDLサービスに適した文字列です。
トピック:
GET(メタデータ読取り)サービスには、そのリクエストがすべての表のメタデータに対するものか、または指定した表のメタデータに対するものであるかに応じて、異なる<nosqlservice>フォーマットおよび出力があります。
すべての表の場合: <nosqlservice> = metadata-catalog/
JSON出力は、各表のメタデータおよびデータの最初のページへのリンクがある次のような形式です。次に例を示します。
{
"items": [
{
"name": "complexUsers",
"links": [
{
"rel": "canonical",
"href": "http://localhost:8080/ords/sales/metadata-catalog/tables/complexUsers/",
"mediaType": "application/json"
},
{
"rel": "describes",
"href": "http://localhost:8080/ords/sales/tables/complexUsers/"
}
]
},
{
"name": "shardUsers",
"links": [
{
"rel": "canonical",
"href": "http://localhost:8080/ords/sales/metadata-catalog/tables/shardUsers/",
"mediaType": "application/json"
},
{
"rel": "describes",
"href": "http://localhost:8080/ords/sales/tables/shardUsers/"
}
]
},
{
"name": "simpleUsers",
"links": [
{
"rel": "canonical",
"href": "http://localhost:8080/ords/sales/metadata-catalog/tables/simpleUsers/",
"mediaType": "application/json"
},
{
"rel": "describes",
"href": "http://localhost:8080/ords/sales/tables/simpleUsers/"
}
]
}
],
"hasMore": false,
"count": 3,
"limit": 25,
"offset": 0,
"links": [
{
"href": "http://localhost:8080/ords/sales/metadata-catalog/",
"rel": "self"
}
]
}
表を指定する場合: <nosqlservice> = metadata-catalog/tables/<name>/(ここで、<name>は表の名前)
JSON出力は、プロパティ、キー、列の詳細、子表、リンクを持つ次のような形式です。次に例を示します。
{
"type": "TABLE",
"name": "simpleUsers",
"fullname": "simpleUsers",
"description": null,
"primarykey": [
"userID"
],
"shardkey": [
"userID"
],
"members": [
{
"name": "firstName",
"type": "STRING",
"description": null
},
{
"name": "lastName",
"type": "STRING",
"description": null
},
{
"name": "userID",
"type": "INTEGER",
"description": null
}
],
"indexes": [
{
"name": "compoundIndex",
"description": null,
"indexfields": [
"lastName",
"firstName"
]
},
{
"name": "simpleIndex",
"description": null,
"indexfields": [
"firstName"
]
}
],
"childtables": [ ],
"links": [
{ "rel": "collection", "href": "http://localhost:8080/ords/sales/metadata-catalog/" },
{
"rel": "canonical",
"href": "http://localhost:8080/ords/sales/metadata-catalog/tables/simpleUsers/",
"mediaType": "application/json"
},
{
"rel": "describes",
"href": "http://localhost:8080/ords/sales/tables/simpleUsers/"
}
]
}
表の項目を指定する場合: <nosqlservice> = metadata-catalog/tables/<name>/item(ここで、<name>は表の名前)
JSON出力は、プロパティ、キー、列の詳細、子表、リンクを持つ次のような形式です。次に例を示します。
{
"name": "simpleUsers",
"fullname": "simpleUsers",
"description": null,
"primarykey": [
"userID"
],
"members": [
{
"name": "firstName",
"type": "STRING",
"description": null
},
{
"name": "lastName",
"type": "STRING",
"description": null
},
{
"name": "userID",
"type": "INTEGER",
"description": null
}
],
"links": [
{
"rel": "collection",
"href": "http://localhost:8080/ords/sales/metadata-catalog/"
},
{
"rel": "canonical",
"href": "http://localhost:8080/ords/sales/metadata-catalog/tables/simpleUsers/item",
"mediaType": "application/json"
}
]
}
GET(データ読取り)サービスには、そのリクエストが表のすべてのデータに対するものか、または表のデータのサブセットに対するものであるかに応じて、異なる<nosqlservice>フォーマットおよび出力があります。
表のすべてのデータの場合: <nosqlservice> = tables/<name>/
JSON出力は次の形式です。データは順不同で戻され、プロパティ・ペアの値、どこに属すのかを示すコレクションからのリンク(編集可能)が含まれています。次に例を示します。
{
"items": [
{
"$version": "rO0ABXcsAAQC5a2Fp3hHLajIZEw7k4elAAAAAAAAAQABAwAAAAEAAAABAAAAAAAEwTE.",
"firstName": "Bob",
"lastName": "Johnson",
"userID": 109,
"links": [
{
"href": "http://localhost:8080/ords/sales/tables/simpleUsers/109",
"rel": "self"
},
{
"href": "http://localhost:8080/ords/sales/metadata-catalog/tables/simpleUsers/item",
"rel": "describedby"
}
]
},
{
"$version": "rO0ABXcsAAQC5a2Fp3hHLajIZEw7k4elAAAAAAAAAKYBAwAAAAEAAAABAAAAAAAEZNg.",
"firstName": "Alex",
"lastName": "Robertson",
"userID": 1,
"links": [
{
"href": "http://localhost:8080/ords/sales/tables/simpleUsers/1",
"rel": "self"
},
{
"href": "http://localhost:8080/ords/sales/metadata-catalog/tables/simpleUsers/item",
"rel": "describedby"
}
]
},……..
"accepts": [
"application/json"
],
"hasMore": false,
"count": 6,
"limit": 25,
"offset": 0,
"links": [
{
"href": "http://localhost:8080/ords/sales/tables/simpleUsers/",
"rel": "edit",
"targetSchema": "application/json"
},
{
"href": "http://localhost:8080/ords/sales/metadata-catalog/tables/simpleUsers/",
"rel": "describedby"
},
{
"href": "http://localhost:8080/ords/sales/tables/simpleUsers/",
"rel": "self"
}
] }
表のデータのキーを指定する場合: <nosqlservice> = tables/<name>/<keys>
<name>は表の名前、<keys>はカンマ区切りの索引キー値のセットです。キー値はキー定義の順番である必要があります。キーのすべての部分が指定されない場合は、取得は部分的なキーに基づきます。完全なキーを指定した場合、出力は単一のアイテムです。
JSONの出力には、プロパティ・ペアの値、およびそれがどこに属するかを示すコレクションからのリンクが含まれています。次の例では、完全なキー(tables/shardUsers/Robertson,Alex)を指定した場合のJSON出力を示します。
{
"$version": "rO0ABXcsAAQC5a2Fp3hHLajIZEw7k4elAAAAAAAAAKYBAwAAAAEAAAABAAAAAAAEZNg.",
"firstName": "Alex",
"lastName": "Robertson",
"userID": 1,
"accepts": [
"application/json"
],
"links": [
{
"href": "http://localhost:8080/ords/sales/tables/simpleUsers/1",
"rel": "self"
},
{
"href": "http://localhost:8080/ords/sales/metadata-catalog/tables/simpleUsers/item",
"rel": "describedby"
},
{
"href": "http://localhost:8080/ords/sales/tables/simpleUsers/1",
"rel": "edit",
"targetSchema": "application/json"
},
{
"href": "http://localhost:8080/ords/sales/tables/simpleUsers/",
"rel": "collection"
}
] }
次の例では、部分的なキー(tables/shardUsers/Robertson)を指定した場合のJSON出力を示します。
{
"items": [
{
"$version": "rO0ABXcsAAQC5a2Fp3hHLajIZEw7k4elAAAAAAAAAMIBAwAAAAEAAAABAAAAAAAEbLw.",
"firstName": "Alex",
"lastName": "Robertson",
"email": "alero@email.com",
"links": [
{
"href": "http://localhost:8080/ords/sales/tables/shardUsers/Robertson,Alex",
"rel": "self"
},
{
"href": "http://localhost:8080/ords/sales/metadata-catalog/tables/shardUsers/item",
"rel": "describedby"
}
]
},
{
"$version": "rO0ABXcsAAQC5a2Fp3hHLajIZEw7k4elAAAAAAAAAMQBAwAAAAEAAAABAAAAAAAEbSE.",
"firstName": "Beatrix",
"lastName": "Robertson",
"email": "bero@email.com",
"links": [
{
"href": "http://localhost:8080/ords/sales/tables/shardUsers/Robertson,Beatrix",
"rel": "self"
},
{
"href": "http://localhost:8080/ords/sales/metadata-catalog/tables/shardUsers/item",
"rel": "describedby"
}
]
}
],
"accepts": [
"application/json"
],
"hasMore": false,
"count": 2,
"limit": 25,
"offset": 0,
"links": [
{
"href": "http://localhost:8080/ords/sales/tables/shardUsers/",
"rel": "edit",
"targetSchema": "application/json"
},
{
"href": "http://localhost:8080/ords/sales/metadata-catalog/tables/shardUsers/",
"rel": "describedby"
},
{
"href": "http://localhost:8080/ords/sales/tables/shardUsers/",
"rel": "up"
},
{
"href": "http://localhost:8080/ords/sales/tables/shardUsers/Robertson",
"rel": "self"
}
] }
表のデータの索引およびキーを指定する場合: <nosqlservice> = tables/<name>/index/<indexname>/<keys>
<name>は表の名前、<indexname>は索引の名前、<keys>はカンマ区切りの索引キー値のセットです。キー値はキー定義の順番である必要があります。キーのすべての部分が指定されない場合は、取得は部分的なキーに基づきます。完全なキーを指定した場合、出力は単一のアイテムです。
JSONの出力には、プロパティ・ペアの値、およびそれがどこに属するかを示すコレクションからのリンク(編集可能)が含まれています。次に例を示します。
{
"items": [
{
"$version": "rO0ABXcsAAQC5a2Fp3hHLajIZEw7k4elAAAAAAAAALIBAwAAAAEAAAABAAAAAAAEaIk.",
"firstName": "Joel",
"lastName": "Robertson",
"userID": 3,
"links": [
{
"href": "http://localhost:8080/ords/sales/tables/simpleUsers/3",
"rel": "self"
},
{
"href": "http://localhost:8080/ords/sales/metadata-catalog/tables/simpleUsers/item",
"rel": "describedby"
}
]
},
{
"$version": "rO0ABXcsAAQC5a2Fp3hHLajIZEw7k4elAAAAAAAAAL4BAwAAAAEAAAABAAAAAAAEa4k.",
"firstName": "Joel",
"lastName": "Jones",
"userID": 6,
"links": [
{
"href": "http://localhost:8080/ords/sales/tables/simpleUsers/6",
"rel": "self"
},
{
"href": "http://localhost:8080/ords/sales/metadata-catalog/tables/simpleUsers/item",
"rel": "describedby"
}
]
}
],
"hasMore": false,
"count": 2,
"limit": 25,
"offset": 0,
"links": [
{
"href": "http://localhost:8080/ords/sales/metadata-catalog/tables/simpleUsers/",
"rel": "describedby"
},
{
"href": "http://localhost:8080/ords/sales/tables/simpleUsers/index/simpleIndex/Joel",
"rel": "self"
},
{
"href": "http://localhost:8080/ords/sales/tables/simpleUsers/",
"rel": "collection"
}
] }
PUT(べき等書込み)サービスでは、その操作がアップサートであるか、存在によってPUTするのか、またはバージョンによってPUTするのかに応じて、異なる<nosqlservice>形式および出力があります。(「Put if version」は、NoSQLデータベースの最新バージョンが示されているバージョンのときのみPUT操作が成功することを意味します。これによって、クライアントが新しい値を古い値で上書きしてしまうことを防ぎます。)
アップサート(存在すれば更新し、存在しなければ作成する)の場合: <nosqlservice> = tables/<name>/
リクエストのボディはJSON形式で、データ読取り(GET)操作によって戻される形式ですが、リンクは含まれません。次に例を示します。
{ "userID": 108, "firstName": "Bob", "lastName": "Johnson"}
存在すればPUTの場合: <nosqlservice> = tables/<name>/<key>
<name>は表の名前、<keys>は新規オブジェクトの主キー値です。
リクエストのボディはJSON形式で、データ読取り(GET)操作によって戻される形式ですが、リンクは含まれません。次に例を示します。
{ "userID": 108, "firstName": "Bob", "lastName": "Johnson"}
その行が存在しない場合、ステータス404(NOT_FOUND)が戻されます。
指定したバージョンが存在すればPUTの場合: <nosqlservice> = tables/<name>/<key>
<name>は表の名前、<keys>は新規オブジェクトの主キー値、ヘッダー・パラメータのIf-Matchはアイテムの$versionプロパティの値を指定します。指定されたバージョンと一致する場合、それが更新されます。
リクエストのボディはJSON形式で、データ読取り(GET)操作によって戻される形式ですが、リンクは含まれません。次に例を示します。
{ "userID": 108, "firstName": "Bob", "lastName": "Johnson"}
If-Match= rO0ABXcsAAQC5a2Fp3hHLajIZEw7k4elAAAAAAAAAL4BAwAAAAEAAAABAAAAAAAEa4k
その行が存在しない場合、ステータス404(NOT_FOUND)が戻されます。行が指定されたバージョンと一致しない場合は、ステータス412(PRECONDITION_FAILED)が戻されます。
関連トピック
POST(存在しなければPUT)サービスの<nosqlservice>の形式: <nosqlservice> = tables/<name>/
<name>は、表の名前です。
リクエストのボディはJSON形式で、データ読取り(GET)操作によって戻される形式ですが、リンクは含まれません。次に例を示します。
{ "userID": 108, "firstName": "Bob", "lastName": "Johnson"}
行が存在している場合は、ステータス400((BAD_REQUEST)この行はすでに存在します)が戻されます。行が存在しない場合は、ステータス201(CREATED)が戻されます。
関連トピック
DELETE(削除)サービスは、オプションでバージョン識別子を指定できます。
バージョンを指定しないDELETE: <nosqlservice> = tables/<name>/<keys>
<name>は表の名前、<keys>は削除する行の主キー値またはカンマ区切りの主キー値のセットです。キーのすべての部分が指定されない場合は、削除は部分的なキーに基づきます。
指定された行が存在する場合、ステータス204(NO_CONTENT)が戻されます。指定された行が存在しない場合は、ステータス404(NOT_FOUND)が戻されます。
バージョンとキーにより1つのオブジェクトのみが戻される(つまり、オブジェクトを完全に指定する)場合のDELETE: <nosqlservice> = tables/<name>/<keys>
<name>は表の名前、<keys>は削除する行の主キー値またはカンマ区切りの主キー値のセット、ヘッダー・パラメータのIf-Matchはアイテムの$versionプロパティの値を指定します。指定されたバージョンと一致する場合、それが削除されます。次に例を示します。
If-Match= rO0ABXcsAAQC5a2Fp3hHLajIZEw7k4elAAAAAAAAAL4BAwAAAAEAAAABAAAAAAAEa4k
指定された行バージョンの組合せが存在している場合は、ステータス204(NO_CONTENT)が戻されます。指定された行は存在しますが、指定されたバージョンでない場合には、ステータス412(PRECONDITION_FAILED)が戻されます。指定された行が存在しない場合は、ステータス404(NOT_FOUND)が戻されます。
NoSQLの表と索引を操作するためのサービスが利用できます。
表リクエストの場合、リクエストのボディは、『Oracle NoSQL Database表スタート・ガイド』の付録A (表データ定義言語概要)で指定されているものに対応するテキスト形式です。
トピック:
DDLの作成および更新操作のサービスの<nosqlservice>の形式: <nosqlservice> = ddl/
例:
http://localhost:8080/ords/sales/ddl/
リクエストのボディには、NoSQLストア上で実行されるDDLを含めます。リクエストのボディの例:
CREATE TABLE IF NOT EXISTS myUsers (firstName STRING,lastName STRING,userID INTEGER,PRIMARY KEY (userID)) CREATE INDEX IF NOT EXISTS myUser_index ON myUsers(lastName, firstName) ALTER TABLE myUsers(ADD newcolumn STRING)
操作が成功した場合、新規リソースの場所を示すLocationヘッダー変数とともに「OK」のステータスが戻されます。たとえば(索引の作成):
Status: 200: OK
Headers:
Location: http://localhost:8080/ords/sales/metadata-catalog/tables/myUsers/index/myUser_index
操作が失敗した場合、エラー・コードが戻されます。
操作が1秒以内に完了しない場合、完了を確認するためのリクエストを送信できるように、タスクIDとともにACCEPTEDのステータスが戻されます。たとえば(索引の作成):
Status: 202: Accepted
Headers:
Location: http://localhost:8080/ords/sales/ddl/tasks/16
DDLのドロップ操作のサービス<nosqlservice>形式: <nosqlservice> = ddl/
例:
http://localhost:8080/ords/sales/ddl/
リクエストのボディには、NoSQLストア上で実行されるDDLを含めます。リクエストのボディの例:
DROP INDEX IF EXISTS myUser_index ON myUsers DROP TABLE IF EXISTS myUsers
操作が成功した場合、NO_CONTENTのステータスが戻されます。
操作が失敗した場合、エラー・コードが戻されます。
操作が1秒以内に完了しない場合、完了を確認するためのリクエストを送信できるように、タスクIDとともにACCEPTEDのステータスが戻されます。例(表のドロップ):
Status: 202: Accepted
Headers:
Location: http://localhost:8080/ords/sales/ddl/tasks/17
ポーリング・サービスの<nosqlservice>形式: <nosqlservice> = ddl/tasks/<id>
例:
http://localhost:8080/ords/sales/ddl/tasks/17
操作が成功した場合、「OK」のステータスが戻され、Locationヘッダーが追加情報を提供できます。
LocationヘッダーがURLリクエストと同じである場合(たとえば、http://localhost:8080/ords/sales/ddl/tasks/17)、タスクはまだ進行中です。
Locationヘッダーが空白またはnullの場合、タスクは完了しており、このタスクはドロップ操作なので新規の場所はありません。
Locationヘッダーが空白ではなく、URLリクエストと同じではない場合は、これは新規または更新されたリソースの場所です。
複数の操作および特定の結果を得るために、いくつかのパラメータのグループを使用できます。
トピック:
GET操作では、?limit={limit}&offset={offset}を使用して制限およびオフセットを指定できます。次に例を示します。
<nosqlservice> = metadata-catalog/?limit=2&offset=1
この例では、2つ目のオブジェクトから(つまり、最初の1つをスキップ)、ページ当たり2つのオブジェクトを戻します。JSON出力は次のようになります。
{
"items": [
{
"name": "evolveUsers",
"links": [
{
"rel": "canonical",
"href": "http://localhost:8080/ords/sales/metadata-catalog/tables/evolveUsers/",
"mediaType": "application/json"
},
{
"rel": "describes",
"href": "http://localhost:8080/ords/sales/tables/evolveUsers/"
}
]
},
{
"name": "shardUsers",
"links": [
{
"rel": "canonical",
"href": "http://localhost:8080/ords/sales/metadata-catalog/tables/shardUsers/",
"mediaType": "application/json"
},
{
"rel": "describes",
"href": "http://localhost:8080/ords/sales/tables/shardUsers/"
}
]
}
],
"hasMore": false,
"count": 2,
"limit": 2,
"offset": 1,
"links": [
{
"href": "http://localhost:8080/ords/sales/metadata-catalog/",
"rel": "self"
},
{
"href": "http://localhost:8080/ords/sales/metadata-catalog/?limit=2",
"rel": "prev"
},
{
"href": "http://localhost:8080/ords/sales/metadata-catalog/?limit=2",
"rel": "first"
}
]
フィールド範囲を使用して取得する行を制限でき、取得する順序を指定できます。このための問合せ構造は、AND条件となるペアのシンプルなリストです。次に例を示します。
?q={"firstName":{"$between":["A","C"]},"$direction":"reverse"}
特殊文字は、URLエンコーディングを使用してエスケープする必要があります。次に例を示します。
http://localhost:8080/ords/sales/tables/simpleUsers/index/simpleIndex/?q={"firstName":{"$between":%5B"A","C"%5D}}
ストア内の関連するデフォルト値を上書きし、方向(順序)、一貫性の保証、および永続性を保証するための値を指定できます。
方向(順序)の場合は、$directionプロパティとして次の値のうちの1つを指定します。
$direction = "forward" | "reverse" | "unordered"
方向(順序)のデフォルトは"forward"です。
キーの一部または空のキーを使用した主キーの取得では、"unordered"のみが許可され、他の値は無視されます。
一貫性の保証は、$consistencyプロパティに次の適切な値を指定します(<LONG>は長い桁の数値を意味することに注意)。
$consistency = <Absolute> | <None> | <Replica> | <Time> | <Version> <Absolute> = "absolute" <None> = "none" <Replica> = "replica" <Time> = <Lag> "," <Timeout> <Lag> = <LONG> "," <Units> <Timeout> = <LONG> "," <Units> <Units> = "nanoseconds" | "microseconds" | "milliseconds" | "seconds" | "minutes" | "hours" | "days" <version> = <version_id> "," <LONG> "," <Units> <version_id> = <version id of item as returned in GET>
次に例を示します。
http://localhost:8080/ords/sales/tables/shardUsers/Robertson,Beatrix?q={"$consistency":"time(3,seconds,2,minutes)"}
永続性の保証は、NoSQL-Write-Optionと呼ばれるヘッダーに次の形式の値を指定します(<LONG>は長い桁の数値を意味することに注意)。
<WriteOption> = (<DurabilityPolicy> | <DurabilityGuarantees>) ";" <WriteTimeOut> <DurabilityPolicy> = "Durability" "=" <DurabilityValue> <DurabilityValue> = "COMMIT_NO_SYNC" | "COMMIT_SYNC" | "COMMIT_WRITE_NO_SYNC" <DurabilityGuarantees> = <MasterSyncPolicy> ";" <ReplcaSyncPolicy> ";" <ReplicaAckPolicy> <MasterSyncPolicy> = "MasterSync" "=" "NO_SYNC" | "SYNC" | "WRITE_NO_SYNC" <ReplicaSyncPolicy> = "ReplicaSync" "=" "NO_SYNC" | "SYNC" | "WRITE_NO_SYNC" <ReplicaAckPolicy> = "ReplicaAck" "=" "ALL" | "NONE" | "SIMPLE_MAJORITY" <WriteTimeOut> = "TimeOut" "=" <LONG> [ ; "Units" "=" <Units>]
たとえば、次のような値でNoSQL-Write-Optionヘッダーを作成します。
Durability = COMMIT_NO_SYNC; TimeOut = 3; Units = seconds