8.1. オブジェクトの作成¶

POST /1/(tenantId)/objects/(bucketName)¶

オブジェクトを作成する。

Request Headers:
	X-Application-Id -- アプリケーションID(必須) X-Application-Key -- アプリケーションキー(必須) X-Session-Token -- セッショントークン(オプション) Content-Type -- "application/json"
Parameters:	bucketName (string) -- バケット名
Query Parameters:
	requestToken (string) -- リクエストトークン
Status Codes:	200 OK -- 正常終了 400 Bad Request -- パラメータ・リクエストボディ不正 401 Unauthorized -- 認証エラー 403 Forbidden -- 権限エラー 404 Not Found -- バケットが存在しない 409 Conflict -- データ重複エラー(duplicate_key), ID衝突(duplicate_id) 413 Request Entity Too Large -- オブジェクトサイズ制限超過 415 Unsupported Media Type -- Content-Type 不正 500 Internal Server Error -- シャードキーの制約によるエラー。その他。

リクエストボディ

リクエストボディには、JSON形式で記述された任意のオブジェクトを指定できる。

以下に例を示す。

{
  "name": "Foo",
  "score": 80,
  "ACL": {
    "r": ["g:authenticated"],
    "w": ["g:authenticated"],
  }
}

"ACL" には ACL を指定できる。ACL を指定しなかった場合は以下の ACL が自動的に設定される。 (ただしバケットの noAcl 属性が true の場合は設定されない)

ログイン済みの場合: 全フィールドが空。オーナ(作成ユーザ)のみがアクセス可。
未ログイン状態の場合 : r, w に "g:anonymous" が設定され、誰でも読み書き可。owner フィールドは設定されない。

また、クライアント側で "_id" フィールドを指定することができる。 _id を指定した場合、サーバは _id の値をそのまま受け入れるが、同一の _id を持つデータが既に存在する場合は 409 Conflict エラーを返す。 _id は MongoDB のオブジェクトIDと同じフォーマットでなければならない。 _id を指定しない場合は、サーバ側で _id を採番する。

また、クライアント側から requestToken を指定することができる。サーバは requestToken が指定された場合、レスポンスをキャッシュする。同一 requestToken を持つリクエストが再送された場合、サーバは処理を行わずキャッシュしたレスポンスのみを返却する。なお、クライアントは requestToken をランダムかつ推測不可能な文字列として作成しなければならない。

レスポンスボディ

レスポンスボディには作成したオブジェクト情報を含むJSON データが返却される。リクエスト時と同じものだが、_id などのフィールドが追加される。 409 Conflictの場合はその原因をJSON形式で返す。

レスポンスボディの例:

{
  "_id": "521c36d4ac521e1ffa000007",
  "name": "Foo",
  "score": 80
  "ACL": {
    "owner": "xxxxx",
    "r": ["g:authenticated"],
    "w": ["g:authenticated"],
  },
  "createdAt": "2013-08-27T05:19:16.000Z",
  "updatedAt": "2013-08-27T05:19:16.000Z",
"etag": "8c92c97e-01a7-11e4-9598-53792c688d1b"
}

追加されるフィールドは以下のとおり。これらのフィールドは予約名のため、これ以外の用途に使用してはならない。

_id : オブジェクトID
createdAt : 作成日時
updatedAt :更新日時
ACL : 指定しなかった場合自動追加される(noAcl = true の場合を除く)。指定した場合でも owner がない場合は owner は自動設定される。
etag : ETag 値。新規作成・更新の度に変更される固有値。

409 Conflict の場合は以下の形式のデータが返却される

{
  "reasonCode": "etag_mismatch"
  "detail": {
    "_id": "521c36d4ac521e1ffa000007",
    "name": "Foo",
    "ACL": { /*…略…*/ },
    "createdAt": "2013-08-27T05:19:16.000Z",
    "updatedAt": "2013-08-27T05:19:16.000Z",
    "etag": "8c92c97e-01a7-11e4-9598-53792c688d1b"
  }
}

reasonCode: 原因を示すコード
- request_conflicted: 更新・削除処理が衝突した場合。
- duplicate_key: データ重複。バケットに設定したインデックスのユニーク制約による。
- duplicate_id: ID重複。オブジェクト作成時に指定したIDが既に存在する
- etag_mismatch: 更新・削除処理でEtagが不一致
detail: エラーに関するデータ

Etag不一致（etag_mismatch）の場合のみサーバ側のデータがJSON形式で格納される

それ以外場合はエラーメッセージが格納される。

注意事項

バケットcontentACLの create 権限が必要
MongoDBの制約として次のフィールド名は使用できない。先頭が"$"であるフィールド名。 "."(ピリオド)を含むフィールド名

8.1.1. データ暗号化¶

MongoDB内のデータ保護を目的として、オブジェクト内の一部フィールドを暗号化してMongoDBに保存することが可能である。

"_protected" フィールドに設定されたデータが暗号化対象となる。ただし、トップレベルの "_protected" フィールドを暗号化対象とし、データ階層内の "_protected" フィールドは暗号化対象外とする。

"_protected" フィールドには、JSON オブジェクト型でデータを設定する。値や文字列等のデータが設定された場合は、400 Bad Request エラーを返す。

{
    "_protected": {"name", "Foo"}, // 暗号化される
    "person": {
      "_protected": {"name", "Bar"} // 暗号化されない
    },
    "_protected": "message" // エラー返却
}

暗号化されたデータを読み出した場合は、"_protected" を復号したデータを返す。したがって、オブジェクトストレージAPIの暗号化有無による使用上の違いは基本的に発生しない。 API個別の注意事項については、各APIの注意事項を参照すること。