リクエストのメッセージの基本的な形式は以下の通りです。
{
"id" : "<メッセージの識別子>",
"type" : "<メッセージの種類>",
"replyTo" : "<レスポンスの受信者へのパス>",
"dataset" : "<対象データセット名>",
"timeout" : <結果を待つ秒数>,
"targetRole" : "<対象となるロール>",
"body" : <メッセージ本文>
}
id
type
replyTo
<ホスト>:<ポート番号>/<タグ名>
で示されたパス文字列。例:localhost:24224/output
.dataset
timeout
0.5
.60
(=1分)targetRole
targetRole
が無い、または特別な値"any"
が指定された場合、そのノードのロールが何であるかに関わらず、メッセージを受信したノードがメッセージを処理します。null
、"any"
、または以下のいずれか:
"service-provider"
"absorb-source"
"absorb-destination"
null
body
null
。レスポンスのメッセージの基本的な形式は以下の通りです。
{
"type" : "<メッセージの種類>",
"inReplyTo" : "<対応するリクエストメッセージの識別子>",
"statusCode" : <ステータスコード>,
"body" : <メッセージの本文>,
"errors" : <ノードから返されたエラー>
}
type
type
の値に .result
という接尾辞を伴った文字列です。inReplyTo
statusCode
レスポンスのステータスコードはHTTPのステータスコードに似ています。
200
およびその他の 2xx
のステータスbody
null
。errors
この情報は、コマンドが複数のボリュームに分散して処理された時にのみ現れます。それ以外の場合、レスポンスメッセージは errors
フィールドを含みません。詳細はエラーレスポンスの説明を参照して下さい。
コマンドの中にはエラーを返す物があります。
エラーレスポンスは通常のレスポンスと同じ type
を伴って返されますが、通常のレスポンスとは異なる statusCode
と body
を持ちます。大まかなエラーの種類は statusCode
で示され、詳細な情報は body
の内容として返されます。
コマンドが複数のボリュームに分散して処理されて、各ボリュームがエラーを返した場合、レスポンスメッセージは errors
フィールドを持ちます。各ボリュームから返されたエラーは以下のように保持されます:
{
"type" : "add.result",
"inReplyTo" : "...",
"statusCode" : 400,
"body" : {
"name": "UnknownTable",
"message": ...
},
"errors" : {
"/path/to/the/node1" : {
"statusCode" : 400,
"body" : {
"name": "UnknownTable",
"message": ...
}
},
"/path/to/the/node2" : {
"statusCode" : 400,
"body" : {
"name": "UnknownTable",
"message": ...
}
}
}
}
このような場合、すべてのエラーの中で代表的な1つがメッセージの body
に出力されます。
エラーレスポンスのステータスコードはHTTPのステータスコードに似ています。
400
およびその他の 4xx
のステータス500
およびその他の 5xx
のステータスbody
エラーレスポンスの body
の基本的な形式は以下の通りです。
{
"name" : "<エラーの種類>",
"message" : "<人間が読みやすい形式で示されたエラーの詳細>",
"detail" : <任意の形式の、追加のエラー情報>
}
追加の情報がない場合、 detail
は出力されないことがあります。
すべてのコマンドに共通するエラーとして、以下の物があります。
MissingDatasetParameter
dataset
の指定がないことを示します。ステータスコードは 400
です。UnknownDataset
404
です。UnknownType
type
に指定されたコマンドを処理するハンドラが存在しない、未知のコマンドであることを示します。ステータスコードは 400
です。