Rename API method categories

This commit is contained in:
mDuo13
2022-06-28 04:09:37 -07:00
parent 42117756c6
commit 3458809228
160 changed files with 279 additions and 257 deletions

View File

@@ -0,0 +1,11 @@
---
html: api-conventions.html
parent: http-websocket-apis.html
blurb: rippled APIのデータ型とフォーマットについて説明します。
template: pagetype-category.html.jinja
---
# APIの規則
このセクションでは、JSON-RPCおよびWebSocketインターフェイスを含む`rippled` APIのデータ型とフォーマットについて説明します。
これらのデータ型の一部は、[Data API](data-api.html)を含む、より高度なAPIにも使用されます。

View File

@@ -0,0 +1,11 @@
---
html: api-conventions.html
parent: http-websocket-apis.html
blurb: Common conventions used across the XRP Ledger's HTTP APIs.
template: pagetype-category.html.jinja
---
# API Conventions
This section describes data types and formats of the HTTP APIs (JSON-RPC and WebSocket) as implemented in [the `rippled` server](xrpl-servers.html).
For information on the XRP Ledger protocol that applies to all APIs, see [Protocol Reference](protocol-reference.html).

View File

@@ -0,0 +1,117 @@
---
html: error-formatting.html
parent: api-conventions.html
blurb: WebSocket、JSON-RPC、コマンドラインインターフェイスのエラーフォーマットと汎用エラーコードです。
---
# エラーのフォーマット
エラーが発生する可能性のある状況をすべて挙げることは不可能です。トランスポートレイヤーで発生する場合(ネットワーク接続が失われる場合など)には、使用しているクライアントとトランスポートに応じてその結果は異なります。ただし、`rippled`サーバーが要求を正常に受信した場合、サーバーは標準のエラー形式での応答を試みます。
**注意:** 要求の結果がエラーになった場合、応答の一部として要求全体がコピーされます。このため、エラーのデバッグに取り組むことができます。ただし、これには要求で渡した機密情報がすべて含まれます。エラーメッセージを共有するときには、アカウントの重要な機密情報を他のユーザーに誤って公開することがないように、十分に注意してください。
エラーの例:
<!-- MULTICODE_BLOCK_START -->
*WebSocket*
```
{
"id": 3,
"status": "error",
"type": "response",
"error": "ledgerIndexMalformed",
"request": {
"account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
"command": "account_info",
"id": 3,
"ledger_index": "-",
"strict": true
}
}
```
*JSON-RPC*
```
HTTP Status: 200 OK
{
"result": {
"error": "ledgerIndexMalformed",
"request": {
"account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
"command": "account_info",
"ledger_index": "-",
"strict": true
},
"status": "error"
}
}
```
*コマンドライン*
```
{
"result": {
"error": "ledgerIndexMalformed",
"request": {
"account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
"command": "account_info",
"ledger_index": "-",
"strict": true
},
"status": "error"
}
}
```
<!-- MULTICODE_BLOCK_END -->
## WebSocketフォーマット
| `Field` | 型 | 説明 |
|:----------|:---------|:------------------------------------------------------|
| `id` | (場合により異なる) | この応答の要求元となったWeb Socket要求に指定されていたID |
| `status` | 文字列 | `"error"`: 要求が原因でエラーが発生した場合 |
| `type` | 文字列 | 通常は`"response"`。これは、コマンドに対し正常に応答したことを示します。 |
| `error` | 文字列 | 発生したエラータイプの一意のコード。 |
| `request` | オブジェクト | このエラーが発生した要求のコピーJSONフォーマット。**注意:** 要求にアカウントの機密情報が含まれている場合、ここにコピーされます。 |
## JSON-RPCフォーマット
一部のJSON-RPC要求は、HTTPレイヤーでエラーコードで応答します。この場合、応答は応答本文にプレーンテキストで記述されます。たとえば`method`パラメーターでコマンドを指定し忘れた場合、応答は次のようになります。
```
HTTP Status: 400 Bad Request
Null method
```
HTTPステータスコード200 OKが返されるその他のエラーの場合、応答はJSONフォーマットで、以下のフィールドが使用されます。
| `Field` | 型 | 説明 |
|:-----------------|:-------|:-------------------------------------------------|
| `result` | オブジェクト | クエリーに対する応答が含まれているオブジェクト |
| `result.error` | 文字列 | 発生したエラータイプの一意のコード。 |
| `result.status` | 文字列 | `"error"`: 要求が原因でエラーが発生した場合 |
| `result.request` | オブジェクト | このエラーが発生した要求のコピーJSONフォーマット。**注意:** 要求にアカウントの機密情報が含まれている場合、ここにコピーされます。**注記:** 発行される要求にかかわらず、要求はWebSocketフォーマットに再設定されます。 |
## 汎用エラー
すべてのメソッドは、以下のいずれかの値の`error`コードを返す可能性があります。
* `unknownCmd` - 要求に、`rippled`サーバーが認識する[コマンド](http-websocket-apis.html)が含まれていません。
* `jsonInvalid` -WebSocketのみ要求は適切なJSONオブジェクトではありません。
* この場合JSON-RPCは、代わりに400 Bad Request HTTPエラーを返します。
* `missingCommand` -WebSocketのみ要求に`command`フィールドが指定されていませんでした。
* この場合JSON-RPCは、代わりに400 Bad Request HTTPエラーを返します。
* `tooBusy` - サーバーの負荷が高すぎるため、現在このコマンドを実行できません。管理者として接続している場合は、通常このエラーが返されることはありません。
* `noNetwork` - サーバーとXRP Ledgerピアツーピアネットワークのその他の部分との接続で問題が発生していますサーバーがスタンドアロンモードで実行されていません
* `noCurrent` - 高い負荷、ネットワークの問題、バリデータ障害、誤った構成、またはその他の問題が原因で、サーバーが現行のレジャーを認識できません。
* `noClosed` - サーバーに決済済みレジャーがありません。通常、このエラーは起動が完了していないことが原因で発生します。
* `wsTextRequired` -WebSocketのみ要求の[opcode](https://tools.ietf.org/html/rfc6455#section-5.2)がテキストではありません。
* `amendmentBlocked` - サーバーの状態が[Amendment blocked](amendments.html#amendment-blocked)であるため、XRP Ledgerネットワークとの同期を維持するために最新バージョンに更新する必要があります。

View File

@@ -0,0 +1,129 @@
---
html: error-formatting.html
parent: api-conventions.html
blurb: Error formats and common error codes for WebSocket, JSON-RPC, and Commandline interfaces.
labels:
- Development
---
# Error Formatting
It is impossible to list all the possible ways an error can occur. Some may occur in the transport layer (for example, loss of network connectivity), in which case the results vary depending on what client and transport you are using. However, if the `rippled` server successfully receives your request, it tries to respond in a standardized error format.
**Caution:** When your request results in an error, the entire request is copied back as part of the response, so that you can try to debug the error. However, this also includes any secrets that were passed as part of the request. When sharing error messages, be very careful not to accidentally expose important account secrets to others.
Some example errors:
<!-- MULTICODE_BLOCK_START -->
*WebSocket*
```json
{
"id": 3,
"status": "error",
"type": "response",
"error": "ledgerIndexMalformed",
"request": {
"account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
"command": "account_info",
"id": 3,
"ledger_index": "-",
"strict": true
}
}
```
*JSON-RPC*
```json
HTTP Status: 200 OK
{
"result": {
"error": "ledgerIndexMalformed",
"request": {
"account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
"command": "account_info",
"ledger_index": "-",
"strict": true
},
"status": "error"
}
}
```
*Commandline*
```json
{
"result": {
"error": "ledgerIndexMalformed",
"request": {
"account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
"command": "account_info",
"ledger_index": "-",
"strict": true
},
"status": "error"
}
}
```
<!-- MULTICODE_BLOCK_END -->
## WebSocket Format
| `Field` | Type | Description |
|:----------|:---------|:------------------------------------------------------|
| `id` | (Varies) | ID provided in the Web Socket request that prompted this response |
| `status` | String | `"error"` if the request caused an error |
| `type` | String | Typically `"response"`, which indicates a successful response to a command. |
| `error` | String | A unique code for the type of error that occurred |
| `request` | Object | A copy of the request that prompted this error, in JSON format. **Caution:** If the request contained any secrets, they are copied here! |
| `api_version` | Number | _(May be omitted)_ The `api_version` specified in the request, if any. |
## JSON-RPC Format
Some JSON-RPC request respond with an error code on the HTTP layer. In these cases, the response is a plain-text explanation in the response body. For example, if you forgot to specify the command in the `method` parameter, the response is like this:
```
HTTP Status: 400 Bad Request
Null method
```
For other errors that returned with HTTP status code 200 OK, the responses are formatted in JSON, with the following fields:
| `Field` | Type | Description |
|:-----------------|:-------|:-------------------------------------------------|
| `result` | Object | Object containing the response to the query |
| `result.error` | String | A unique code for the type of error that occurred |
| `result.status` | String | `"error"` if the request caused an error |
| `result.request` | Object | A copy of the request that prompted this error, in JSON format. **Caution:** If the request contained any account secrets, they are copied here! **Note:** The request is re-formatted in WebSocket format, regardless of the request made. |
## Universal Errors
All methods can potentially return any of the following values for the `error` code:
- `amendmentBlocked` - The server is [amendment blocked](amendments.html#amendment-blocked) and needs to be updated to the latest version to stay synced with the XRP Ledger network.
- `failedToForward` - ([Reporting Mode][] servers only) The server tried to forward this request to a P2P Mode server, but the connection failed.
- `invalid_API_version` - The server does not support the [API version number](request-formatting.html#api-versioning) from the request.
- `jsonInvalid` - (WebSocket only) The request is not a proper JSON object.
- JSON-RPC returns a 400 Bad Request HTTP error in this case instead.
- `missingCommand` - (WebSocket only) The request did not specify a `command` field.
- JSON-RPC returns a 400 Bad Request HTTP error in this case instead.
- `noClosed` - The server does not have a closed ledger, typically because it has not finished starting up.
- `noCurrent` - The server does not know what the current ledger is, due to high load, network problems, validator failures, incorrect configuration, or some other problem.
- `noNetwork` - The server is having trouble connecting to the rest of the XRP Ledger peer-to-peer network (and is not running in stand-alone mode).
- `tooBusy` - The server is under too much load to do this command right now. Generally not returned if you are connected as an admin.
- `unknownCmd` - The request does not contain a [command](http-websocket-apis.html) that the `rippled` server recognizes.
- `wsTextRequired` - (WebSocket only) The request's [opcode](https://tools.ietf.org/html/rfc6455#section-5.2) is not text. <!-- SPELLING_IGNORE: opcode -->
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

View File

@@ -0,0 +1,10 @@
---
html: markers-and-pagination.html
parent: api-conventions.html
blurb: 大きなクエリを複数の応答にページネーションする際の慣例です。
---
# マーカーとページネーション
一部のメソッドから返されるデータは、1つの応答に実質的に収まらないことがあります。結果全体が収まらない場合、応答には`marker`フィールドが含まれます。このフィールドを使用することで、複数回の呼出しを通じてデータのページをさらに取得できます。各要求で直前の応答の`marker`値を渡して、終わったところから再開します。応答に`marker`が含まれていなければ、データセットの終わりに達しています。
`marker`フィールドのフォーマットは意図的に未定義になっています。各サーバーで`marker`をそれぞれに合わせて定義できるので、このフィールドの形式は文字列、ネストオブジェクトなどさまざまです。異なるサーバー、または同じサーバーの異なるメソッドでは、異なる`marker`定義を使用できます。各`marker`は一時的であり、10分以上経過すると予期されているとおりに機能しなくなることがあります。

View File

@@ -0,0 +1,10 @@
---
html: markers-and-pagination.html
parent: api-conventions.html
blurb: Convention for paginating large queries into multiple responses.
---
# Markers and Pagination
Some methods return more data than can efficiently fit into one response. When there are more results than contained, the response includes a `marker` field. You can use this to retrieve more pages of data across multiple calls. In each request, pass the `marker` value from the previous response to resume from the point where you left off. If the `marker` is omitted from a response, then you have reached the end of the data set.
The format of the `marker` field is intentionally undefined. Each server can define a `marker` field as desired, so it may take the form of a string, a nested object, or another type. Different servers, and different methods provided by the same server, can have different `marker` definitions. Each `marker` is ephemeral, and may not work as expected after 10 minutes.

View File

@@ -0,0 +1,69 @@
---
html: rate-limiting.html
parent: api-conventions.html
blurb: Information on how public APIs limit clients from making too many requests.
labels:
- Core Server
---
# Rate Limiting
The `rippled` server limits the rate at which API clients can make requests on public APIs. Rate limiting is based on the IP address of the client, so clients behind [network address translation](https://en.wikipedia.org/wiki/Network_address_translation) share a limit based on their public IP address.
**Tip:** Rate limiting does not apply when the client is connected [as an admin](get-started-using-http-websocket-apis.html#admin-access).
When a client is approaching the rate limit, the server adds the field `"warning": "load"` at the top level of an [API response](response-formatting.html). This warning is not added to every response, but the server may send several such warnings before it disconnects a client.
If a client goes past the rate limit, the server disconnects that client and does not serve further requests from the client's API address for a while. The WebSocket and JSON-RPC APIs use different disconnect messages.
## WebSocket API Disconnect Message
For the WebSocket API, the server closes the connection and provides a close message and code. The way you access these messages depends on your WebSocket client implementation. For example, using the [Node.js ws library](https://github.com/websockets/ws), the following code prints the close reason when disconnected:
```js
const WebSocket = require('ws')
const ws = new WebSocket('ws://localhost:6007/')
ws.on('close', (code,reason) => {
console.log("Disconnected. \ncode: ", code, "\nreason: ", reason)
})
// If rate limited, prints:
// Disconnected.
// code: 1008
// reason: threshold exceeded
```
If the connection is closed because of rate limiting, the close code is `1008` and the close message is the string `threshold exceeded`.
## JSON-RPC Rate Limited Error
For a JSON-RPC API request, the server responds with the HTTP status code **503 Service Unavailable** when the client is over the rate limit. This response has a text (not JSON) body stating that the server is overloaded:
```text
503 Service Unavailable
Server is overloaded
```
## Rate Per Request
[[Source]](https://github.com/ripple/rippled/blob/master/src/ripple/resource/Fees.h "Source")
The server calculates a client's usage rate based on the number of requests made over time, and weighs different types of requests based on approximately how much work the server must do to serve them. Follow-up messages from the server for the [subscribe method][] and [path_find method][] also count towards a client's usage rate.
The usage rate drops off exponentially over time, so a client that does not make requests automatically has its access restored after a period of seconds to minutes.
## See Also
- **Concepts:**
- [The `rippled` Server](xrpl-servers.html)
- [Software Ecosystem](software-ecosystem.html)
- **Tutorials:**
- [Getting Started with XRP Ledger APIs](get-started-using-http-websocket-apis.html)
- [Troubleshooting rippled](troubleshoot-the-rippled-server.html)
- **References:**
- [rippled API Reference](http-websocket-apis.html)
- [Error Formatting](error-formatting.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

View File

@@ -0,0 +1,75 @@
---
html: request-formatting.html
parent: api-conventions.html
blurb: WebSocket、JSON-RPC、コマンドラインインターフェイスの標準の要求フォーマットと例です。
---
# 要求フォーマット
## WebSocketフォーマット
`rippled`サーバーへのWebSocketを開いた後、以下の属性を使用して、コマンドを[JSON](https://en.wikipedia.org/wiki/JSON)オブジェクトとして送信できます。
* コマンド名を最上位の`"command"`フィールドに指定します。
* このコマンドのすべての関連パラメーターも最上位に指定します。
* オプションで、任意の値を指定した`"id"`フィールドを指定します。この要求への応答では、同一の`"id"`フィールドを使用します。そうすることで、応答が順不同で到達した場合も、どの要求によってどの応答を得られたのかがわかります。
応答はJSONオブジェクトとして返されます。
## JSON-RPCフォーマット
JSON-RPC要求を実行するには、`rippled`サーバーがJSON-RPC接続をリッスンしているポートおよびIPで、HTTP **POST**要求をルートパス(`/`に送信します。HTTP/1.0またはHTTP/1.1を使用できます。HTTPSを使用する場合は、TLS v1.2を使用してください。セキュリティ上の理由から、`rippled`ではSSL v3以前を _サポートしていません_
常に`Content-Type`ヘッダー(値`application/json`)を指定してください。
複数の要求を実行する予定の場合は、要求間で接続を閉じてから開く操作を行わずに済むように、[Keep-Alives](http://tools.ietf.org/html/rfc7230#section-6.3)を使用してください。
以下の属性を指定した要求本文を[JSON](https://en.wikipedia.org/wiki/JSON)オブジェクトとして送信します。
* コマンドを最上位の`"method"` フィールドに指定します。
* 最上位の`"params"`フィールドを指定します。このフィールドの内容は、コマンドのすべてのパラメーターが指定された1つの入れ子JSONオブジェクトのみを保持している**1要素配列**です。
応答もJSONオブジェクトです。
## コマンドライン形式
コマンドラインでは、通常の(ダッシュが先頭に付いた)コマンドラインオプションの後にコマンドを指定し、その後に一連の限定的なパラメーターをスペースで区切って指定します。スペースやその他の特殊文字が含まれている可能性のあるパラメーター値は、一重引用符で囲みます。
### 要求の例
<!-- MULTICODE_BLOCK_START -->
*WebSocket*
```
{
"id": 2,
"command": "account_info",
"account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
"strict": true,
"ledger_index": "validated"
}
```
*JSON-RPC*
```
POST http://s1.ripple.com:51234/
{
"method": "account_info",
"params": [
{
"account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
"strict": true,
"ledger_index": "validated"
}
]
}
```
*コマンドライン*
```
rippled account_info r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 validated true
```
<!-- MULTICODE_BLOCK_END -->

View File

@@ -0,0 +1,138 @@
---
html: request-formatting.html
parent: api-conventions.html
blurb: Standard request format, with examples, for the WebSocket, JSON-RPC, and Commandline interfaces.
---
# Request Formatting
## Example Request
<!-- MULTICODE_BLOCK_START -->
*WebSocket*
```json
{
"id": 2,
"command": "account_info",
"account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
"strict": true,
"ledger_index": "validated",
"api_version": 1
}
```
*JSON-RPC*
```json
POST http://s1.ripple.com:51234/
Content-Type: application/json
{
"method": "account_info",
"params": [
{
"account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
"strict": true,
"ledger_index": "validated",
"api_version": 1
}
]
}
```
*Commandline*
```sh
rippled account_info r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 validated strict
```
<!-- MULTICODE_BLOCK_END -->
## WebSocket Format
After you open a WebSocket to the `rippled` server, you can send commands as a [JSON](https://en.wikipedia.org/wiki/JSON) object with the following fields:
| Field | Type | Description |
|:--------------------|:----------|:-------------------------------------------|
| `command` | String | The name of the [API method](public-api-methods.html). |
| `id` | (Various) | _(Optional)_ A unique value to identify this request. The response to this request uses the same `id` field. This way, even if responses arrive out of order, you know which request prompted which response. |
| `api_version` | Number | _(Optional)_ The API version to use. If omitted, use version 1. For details, see [API Versioning](#api-versioning). [New in: rippled 1.5.0][] |
| (Method Parameters) | (Various) | Provide any parameters to the method at the top level. |
See [Response Formatting](response-formatting.html) for the response from the server.
## JSON-RPC Format
To make a JSON-RPC request, send an HTTP **POST** request to the root path (`/`) on the port and IP where the `rippled` server is listening for JSON-RPC connections. You can use HTTP/1.0 or HTTP/1.1. If you use HTTPS, you should use TLS version 1.2. For security reasons, `rippled` _does not support_ SSL version 3 or earlier.
Always include a `Content-Type` header with the value `application/json`.
If you plan on making multiple requests, use [Keep-Alives](http://tools.ietf.org/html/rfc7230#section-6.3) so that you do not have to close and re-open the connection in between requests. <!-- SPELLING_IGNORE: alives -->
Send request body as a [JSON](https://en.wikipedia.org/wiki/JSON) object with the following fields:
| Field | Type | Description |
|:--------------------|:----------|:-------------------------------------------|
| `method` | String | The name of the [API method](public-api-methods.html). |
| `params` | Array | _(Optional)_ A **one-item array** containing a nested JSON object with the parameters to this method. You may omit this field if the method does not require any parameters. |
The object inside the `params` array can contain the following fields:
| Field | Type | Description |
|:--------------------|:----------|:-------------------------------------------|
| `api_version` | Number | _(Optional)_ The API version to use. If omitted, use version 1. For details, see [API Versioning](#api-versioning). [New in: rippled 1.5.0][] |
| (Method Parameters) | (Various) | Provide any parameters to the method here. |
See [Response Formatting](response-formatting.html) for the response from the server.
## Commandline Format
Put the API method name after any normal (dash-prefaced) commandline options, followed by a limited set of parameters, separated by spaces. For any parameter values that might contain spaces or other unusual characters, use single-quotes to encapsulate them. Not all methods have commandline API syntax. For more information, see [Commandline Usage](https://xrpl.org/commandline-usage.html#client-mode-options).
The commandline calls JSON-RPC, so its responses always match the JSON-RPC [response format](response-formatting.html).
The commandline always uses the latest [API version](#api-versioning).
**Caution:** The commandline interface is intended for administrative purposes only and is _not a supported API_. New versions of `rippled` may introduce breaking changes to the commandline API without warning!
## API Versioning
The `rippled` server uses a single integer to identify the API version to use. The first API version is `1`; currently, this is the only version of the `rippled` API. (There is no API version 0.) [New in: rippled 1.5.0][]
Future versions of `rippled` that introduce breaking changes will introduce a new API version number, such as `2`. The server will support a range of API versions, which it reports in the `version` API method. <!-- TODO: add a link when `version` method is documented. --> <!-- Uncomment when multiple API versions exist: Separate API requests can use different API versions even on the same persistent connection. For example, if you connect WebSocket to a server that supports API versions 1 and 2, you can make a server_info request using API version 2 and then make another server_info request using API version 1 from the same connection. -->
### Breaking Changes
The following types of changes are **breaking changes**:
- Removing or renaming a field of a request or response.
- Changing the type of a field of a request or response.
- Changing the meaning of a field of a request or a response.
- Changing the order of positional parameters, or adding a new field before other positional parameters.
- Removing or renaming an API method.
- Changing the behavior of an API function visible to existing clients.
- The following types of breaking changes only apply to the gRPC API:
- Changing a `proto` field number.
- Removing or renaming an enum or enum value.
- Adding or removing fields from a `oneof`.
- Splitting or merging a `oneof`.
- Changing whether a message field is `optional`, `repeated`, or `required`.
- Changing the stream value of a request or response.
- Deleting or renaming a package or service.
Any time a full release introduces a breaking change, it introduces a new API version number. Pre-release, beta, and development versions may introduce breaking changes to the same API version number.
### Non-Breaking Changes
The following types of changes are **non-breaking changes** and may occur without a change of API version number:
- Adding a new field to a request or response, not including positional parameters.
- Adding a new API method.
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

View File

@@ -0,0 +1,93 @@
---
html: response-formatting.html
parent: api-conventions.html
blurb: WebSocket、JSON-RPC、コマンドラインインターフェイスの応答のフォーマットとその応答に含まれるフィールド。
---
# 応答フォーマット
`rippled` APIからの応答のフォーマットは、メソッドが呼び出されたインターフェイスWebSocket、JSON-RPC、コマンドラインに応じて多少異なります。コマンドラインインターフェイスがJSON-RPCを呼び出すため、コマンドラインインターフェイスとJSON-RPCインターフェイスは同じフォーマットを使用します。
成功した場合の応答に含まれるフィールドは、以下の通りです。
| `Field` | 型 | 説明 |
|:----------------|:---------|:------------------------------------------------|
| `id` | (場合により異なる) | WebSocketのみこの応答の要求元となった要求で指定されているID。 |
| `status` | 文字列 | WebSocketのみ値が`success`である場合、要求がサーバーによって正常に受信され、理解されたことを示します。 |
| `result.status` | 文字列 | JSON-RPCおよびコマンドライン値が`success`である場合、要求がサーバーによって正常に受信され、理解されたことを示します。 |
| `type` | 文字列 | WebSocketのみ値が`response`の場合、コマンドに対する正常な応答であることを示します。[非同期の通知](subscribe.html)では、`ledgerClosed``transaction`など異なる値が使用されます。 |
| `result` | オブジェクト | クエリーの結果。内容はコマンドによって異なります。 |
## 成功した場合の応答の例
<!-- MULTICODE_BLOCK_START -->
*WebSocket*
```
{
"id": 2,
"status": "success",
"type": "response",
"result": {
"account_data": {
"Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
"Balance": "27389517749",
"Flags": 0,
"LedgerEntryType": "AccountRoot",
"OwnerCount": 18,
"PreviousTxnID": "B6B410172C0B65575D89E464AF5B99937CC568822929ABF87DA75CBD11911932",
"PreviousTxnLgrSeq": 6592159,
"Sequence": 1400,
"index": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05"
},
"ledger_index": 6760970
}
}
```
*JSON-RPC*
```
HTTP Status: 200 OK
{
"result": {
"account_data": {
"Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
"Balance": "27389517749",
"Flags": 0,
"LedgerEntryType": "AccountRoot",
"OwnerCount": 18,
"PreviousTxnID": "B6B410172C0B65575D89E464AF5B99937CC568822929ABF87DA75CBD11911932",
"PreviousTxnLgrSeq": 6592159,
"Sequence": 1400,
"index": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05"
},
"ledger_index": 6761012,
"status": "success"
}
}
```
*コマンドライン*
```
{
"result": {
"account_data": {
"Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
"Balance": "27389517749",
"Flags": 0,
"LedgerEntryType": "AccountRoot",
"OwnerCount": 18,
"PreviousTxnID": "B6B410172C0B65575D89E464AF5B99937CC568822929ABF87DA75CBD11911932",
"PreviousTxnLgrSeq": 6592159,
"Sequence": 1400,
"index": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05"
},
"ledger_index": 6761012,
"status": "success"
}
}
```
<!-- MULTICODE_BLOCK_END -->

View File

@@ -0,0 +1,201 @@
---
html: response-formatting.html
parent: api-conventions.html
blurb: Standard response format, with examples, for the WebSocket, JSON-RPC, and Commandline interfaces.
---
# Response Formatting
Responses are formatted slightly differently based on whether the method is called with the WebSocket, JSON-RPC, or Commandline interfaces. The Commandline and JSON-RPC interfaces use the same format because the Commandline interface calls JSON-RPC.
The fields of a successful response include:
| `Field` | Type | Description |
|:----------------|:---------|:------------------------------------------------|
| `id` | (Varies) | (WebSocket only) ID provided in the request that prompted this response |
| `status` | String | (WebSocket only) The value `success` indicates the request was successfully received and understood by the server. Some [client libraries](client-libraries.html) omit this field on success. |
| `result.status` | String | (JSON-RPC and Commandline) The value `success` indicates the request was successfully received and understood by the server. Some [client libraries](client-libraries.html) omit this field on success. |
| `type` | String | (WebSocket only) The value `response` indicates a direct response to an API request. [Asynchronous notifications](subscribe.html) use a different value such as `ledgerClosed` or `transaction`. |
| `result` | Object | The result of the query; contents vary depending on the command. |
| `warning` | String | _(May be omitted)_ If this field is provided, the value is the string `load`. This means the client is approaching the [rate limiting](rate-limiting.html) threshold where the server will disconnect this client. <!-- STYLE_OVERRIDE: will --> |
| `warnings` | Array | _(May be omitted)_ If this field is provided, it contains one or more **Warnings Objects** with important warnings. For details, see [API Warnings](#api-warnings). [New in: rippled 1.5.0][] |
| `forwarded` | Boolean | _(May be omitted)_ If `true`, this request and response have been forwarded from a [Reporting Mode][] server to a P2P Mode server (and back) because the request requires data that is not available in Reporting Mode. The default is `false`. |
## Example Successful Response
<!-- MULTICODE_BLOCK_START -->
*WebSocket*
```json
{
"id": 2,
"status": "success",
"type": "response",
"result": {
"account_data": {
"Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
"Balance": "27389517749",
"Flags": 0,
"LedgerEntryType": "AccountRoot",
"OwnerCount": 18,
"PreviousTxnID": "B6B410172C0B65575D89E464AF5B99937CC568822929ABF87DA75CBD11911932",
"PreviousTxnLgrSeq": 6592159,
"Sequence": 1400,
"index": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05"
},
"ledger_index": 6760970
}
}
```
*JSON-RPC*
```json
HTTP Status: 200 OK
{
"result": {
"account_data": {
"Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
"Balance": "27389517749",
"Flags": 0,
"LedgerEntryType": "AccountRoot",
"OwnerCount": 18,
"PreviousTxnID": "B6B410172C0B65575D89E464AF5B99937CC568822929ABF87DA75CBD11911932",
"PreviousTxnLgrSeq": 6592159,
"Sequence": 1400,
"index": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05"
},
"ledger_index": 6761012,
"status": "success"
}
}
```
*Commandline*
```json
{
"result": {
"account_data": {
"Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
"Balance": "27389517749",
"Flags": 0,
"LedgerEntryType": "AccountRoot",
"OwnerCount": 18,
"PreviousTxnID": "B6B410172C0B65575D89E464AF5B99937CC568822929ABF87DA75CBD11911932",
"PreviousTxnLgrSeq": 6592159,
"Sequence": 1400,
"index": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05"
},
"ledger_index": 6761012,
"status": "success"
}
}
```
<!-- MULTICODE_BLOCK_END -->
## API Warnings
When the response contains a `warnings` array, each member of the array represents a separate warning from the server. Each such **Warning Object** contains the following fields:
| `Field` | Type | Description |
|:----------|:-------|:--------------------------------------------------------|
| `id` | Number | A unique numeric code for this warning message. |
| `message` | String | A human-readable string describing the cause of this message. Do not write software that relies the contents of this message; use the `id` (and `details`, if applicable) to identify the warning instead. |
| `details` | Object | _(May be omitted)_ Additional information about this warning. The contents vary depending on the type of warning. |
The following reference describes all possible warnings.
### 1001. Unsupported amendments have reached majority
Example warning:
```json
"warnings" : [
{
"details" : {
"expected_date" : 864030,
"expected_date_UTC" : "2000-Jan-11 00:00:30.0000000 UTC"
},
"id" : 1001,
"message" : "One or more unsupported amendments have reached majority. Upgrade to the latest version before they are activated to avoid being amendment blocked."
}
]
```
This warning indicates that the one or more [amendments](amendments.html) to the XRP Ledger protocol are scheduled to become enabled, but the current server does not have an implementation for those amendments. If those amendments become enabled, the current server will become [amendment blocked](amendments.html#amendment-blocked), so you should [upgrade to the latest `rippled` version](install-rippled.html) as soon as possible. <!-- STYLE_OVERRIDE: will -->
The server only sends this warning if the client is [connected as an admin](get-started-using-http-websocket-apis.html#admin-access).
This warning includes a `details` field with the following fields:
| Field | Value | Description |
|:--------------------|:-------|:----------------------------------------------|
| `expected_date` | Number | The time that the first unsupported amendment is expected to become enabled, in [seconds since the Ripple Epoch][]. |
| `expected_date_UTC` | String | The timestamp, in UTC, when the first unsupported amendment is expected to become enabled. |
Due to the variation in ledger close times, these times are approximate. It is also possible that the amendment fails to maintain support from >80% of validators until the specified time, and does not become enabled at the expected time. The server will not become amendment blocked so long as the unsupported amendments do not become enabled.
### 1002. This server is amendment blocked
Example warning:
```json
"warnings" : [
{
"id" : 1002,
"message" : "This server is amendment blocked, and must be updated to be able to stay in sync with the network."
}
]
```
This warning indicates that the server is [amendment blocked](amendments.html#amendment-blocked) and can no longer remain synced with the XRP Ledger.
The server administrator must [upgrade `rippled`](install-rippled.html) to a version that supports the activated amendments.
### 1003. This is a reporting server
[New in: rippled 1.7.0][]
Example warning:
```json
"warnings" : [
{
"id" : 1003,
"message" : "This is a reporting server. The default behavior of a reporting server is to only return validated data. If you are looking for not yet validated data, include \"ledger_index : current\" in your request, which will cause this server to forward the request to a p2p node. If the forward is successful the response will include \"forwarded\" : \"true\""
}
]
```
This warning indicates that the server answering the request is running [Reporting Mode][]. Certain API methods are not available or behave differently because Reporting Mode does not connect to the peer-to-peer network and does not track ledger data that has not yet been validated.
It is generally safe to ignore this warning.
**Caution:** If you request ledger data without explicitly [specifying a ledger version][Specifying Ledgers], Reporting Mode uses the latest validated ledger by default instead of the current in-progress ledger.
## See Also
- [Request Formatting](request-formatting.html)
- [Error Formatting](error-formatting.html) for unsuccessful API responses.
- **Concepts:**
- [The `rippled` Server](xrpl-servers.html)
- [Introduction to Consensus](intro-to-consensus.html)
- [Amendments](amendments.html)
- [Known Amendments](known-amendments.html)
- **Tutorials:**
- [Get Started with XRP Ledger APIs](get-started-using-http-websocket-apis.html)
- [Install and Update `rippled`](install-rippled.html)
- **References:**
- [feature method][]
- [server_info method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

View File

@@ -0,0 +1,27 @@
---
html: rippled-server-states.html
parent: api-conventions.html
blurb: 一部のAPIメソッドで報告される状態情報の定義です。
labels:
- コアサーバー
---
# rippledサーバーの状態
`rippled`サーバーの設定、稼働時間、その他の要素により、サーバーがグローバルなXRP Ledgerピアツーピアネットワークに参加する度合いは異なります。これは、[server_infoメソッド][]と[server_stateメソッド][]への応答内の`server_state`フィールドに示されます。応答は昇順のやり取りに従い、後の値は前の値より優先されます。これらの応答の定義を以下に示します(優先順位の高い順)。
| `Value` | 説明 |
|:---------------|:------------------------------------------------------------|
| `disconnected` | サーバーはXRP Ledgerピアツーピアネットワークにまったく接続されていません。オフラインモードで稼働しているか、何らかの理由でネットワークにアクセスできない可能性があります。 |
| `connected` | サーバーはネットワークに接続されていると考えられます。 |
| `syncing` | サーバーは現在、レジャーバージョンの状態に追いついていません。(通常、サーバーが始動後に最新状態になるまで数分かかります。) |
| `tracking` | サーバーはネットワークに接続しています。 |
| `full` | サーバーはネットワークに完全に組み込まれ、検証にも参加できますが、参加していません(検証者として設定されていないことが原因と考えられます)。 |
| `validating` | サーバーは現在、レジャーの検証に参加しています。 |
| `proposing` | サーバーはレジャーの検証に参加しており、現在、自身のバージョンを提案中です。 |
**注記:** `full``validating``proposing`の区別は、グローバルネットワークの他者との同期の状況に基づいていますが、通常サーバーの上記の状態は一般的なオペレーションの中で変動します。
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

View File

@@ -0,0 +1,27 @@
---
html: rippled-server-states.html
parent: api-conventions.html
blurb: Definitions of state information reported in some API methods.
labels:
- Core Server
---
# rippled Server States
Depending on how the `rippled` server is configured, how long it has been running, and other factors, a server may be participating in the global XRP Ledger peer-to-peer network to different degrees. This is represented as the `server_state` field in the responses to the [server_info method][] and [server_state method][]. The possible responses follow a range of ascending interaction, with each later value superseding the previous one. Their definitions are as follows (in order of increasing priority):
| `Value` | Description |
|:---------------|:------------------------------------------------------------|
| `disconnected` | The server is not connected to the XRP Ledger peer-to-peer network whatsoever. It may be running in offline mode, or it may not be able to access the network for whatever reason. |
| `connected` | The server believes it is connected to the network. |
| `syncing` | The server is currently behind on ledger versions. (It is normal for a server to spend a few minutes catching up after you start it.) |
| `tracking` | The server is in agreement with the network |
| `full` | The server is fully caught-up with the network and could participate in validation, but is not doing so (possibly because it has not been configured as a validator). |
| `validating` | The server is currently participating in validation of the ledger |
| `proposing` | The server is participating in validation of the ledger and currently proposing its own version. |
**Note:** The distinction between `full`, `validating`, and `proposing` is based on synchronization with the rest of the global network, and it is normal for a server to fluctuate between these states as a course of general operation.
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}