mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-23 13:15:49 +00:00
Migrate content syntax via script
The changes in this commit were auto-generated by running tool/migrate.sh Following this commit, the Dactyl build no longer works but the Redocly build (mostly) should.
This commit is contained in:
@@ -7,9 +7,9 @@ labels:
|
||||
---
|
||||
# Compact Transaction Identifier
|
||||
|
||||
A Compact Transaction Identifier (CTID) is a unique identifier for a validated transaction that applies across any [network](parallel-networks.html), not just the XRP Ledger Mainnet.
|
||||
A Compact Transaction Identifier (CTID) is a unique identifier for a validated transaction that applies across any [network](../../../concepts/networks-and-servers/parallel-networks.md), not just the XRP Ledger Mainnet.
|
||||
|
||||
The differences between a CTID and a transaction's [identifying hash](transactions.html#identifying-transactions) are as follows:
|
||||
The differences between a CTID and a transaction's [identifying hash](../../../concepts/transactions/index.md#identifying-transactions) are as follows:
|
||||
|
||||
- A CTID identifies a validated transaction based on its network ID, ledger index, and position within the ledger. Since it specifies which network a transaction has been validated on, it can be used in contexts where you are interacting with more than one network, such as connecting to sidechains. A CTID is 64 bits, typically written as 16 characters of uppercase hexadecimal starting with `C`, for example `C005523E00000000`.
|
||||
- An transaction's identifying hash identifies a signed transaction based on its contents, regardless of if that transaction has been validated on any chains. Since it's a cryptographic hash, it can also be used to prove that the transaction contents are intact. A transaction hash is 256 bits, typically written as 64 characters of hexadecimal, for example `E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7`.
|
||||
@@ -22,8 +22,8 @@ A CTID contains the following parts, in order (big-endian):
|
||||
|
||||
1. 4 bits: The hex nibble `C` indicating that this is a CTID.
|
||||
2. 28 bits: The ledger index of the ledger where the transaction was validated.
|
||||
3. 16 bits: The transaction index, its place within the ledger's canonical order. This is provided as the field `TransactionIndex` in [transaction metadata](transaction-metadata.html).
|
||||
4. 16 bits: The [network ID](transaction-common-fields.html#networkid-field) of the network that validated this transaction.
|
||||
3. 16 bits: The transaction index, its place within the ledger's canonical order. This is provided as the field `TransactionIndex` in [transaction metadata](../../protocol/transactions/metadata.md).
|
||||
4. 16 bits: The [network ID](../../protocol/transactions/common-fields.md#networkid-field) of the network that validated this transaction.
|
||||
|
||||
**Note:** The ledger index is normally stored as a 32-bit unsigned integer which increases by 1 each time a new ledger is created. If a network's ledger index is greater than 268,435,455, it won't fit in 28 bits, so the leading `C` should be incremented to `D`, `E`, or `F` as necessary. This is not expected to be necessary until at least the year 2043.
|
||||
|
||||
|
||||
@@ -14,10 +14,9 @@ It is impossible to list all the possible ways an error can occur. Some may occu
|
||||
|
||||
Some example errors:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
{% tabs %}
|
||||
|
||||
{% tab label="WebSocket" %}
|
||||
```json
|
||||
{
|
||||
"id": 3,
|
||||
@@ -33,9 +32,9 @@ Some example errors:
|
||||
}
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
{% tab label="JSON-RPC" %}
|
||||
```json
|
||||
HTTP Status: 200 OK
|
||||
|
||||
@@ -52,9 +51,9 @@ HTTP Status: 200 OK
|
||||
}
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
*Commandline*
|
||||
|
||||
{% tab label="Commandline" %}
|
||||
```json
|
||||
{
|
||||
"result": {
|
||||
@@ -69,8 +68,9 @@ HTTP Status: 200 OK
|
||||
}
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
{% /tabs %}
|
||||
|
||||
|
||||
## WebSocket Format
|
||||
@@ -108,9 +108,9 @@ For other errors that returned with HTTP status code 200 OK, the responses are f
|
||||
|
||||
All methods can potentially return any of the following values for the `error` code:
|
||||
|
||||
- `amendmentBlocked` - The server is [amendment blocked](amendments.html#amendment-blocked-servers) and needs to be updated to the latest version to stay synced with the XRP Ledger network.
|
||||
- `amendmentBlocked` - The server is [amendment blocked](../../../concepts/networks-and-servers/amendments.md#amendment-blocked-servers) 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.
|
||||
- `invalid_API_version` - The server does not support the [API version number](request-formatting.md#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.
|
||||
@@ -119,11 +119,7 @@ All methods can potentially return any of the following values for the `error` c
|
||||
- `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.
|
||||
- `unknownCmd` - The request does not contain a [command](../index.md) 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' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -2,10 +2,14 @@
|
||||
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
|
||||
metadata:
|
||||
indexPage: true
|
||||
---
|
||||
# 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).
|
||||
This section describes data types and formats of the HTTP APIs (JSON-RPC and WebSocket) as implemented in [the `rippled` server](../../../concepts/networks-and-servers/index.md).
|
||||
|
||||
For information on the XRP Ledger protocol that applies to all APIs, see [Protocol Reference](protocol-reference.html).
|
||||
For information on the XRP Ledger protocol that applies to all APIs, see [Protocol Reference](../../protocol/index.md).
|
||||
|
||||
|
||||
{% child-pages /%}
|
||||
|
||||
@@ -9,14 +9,14 @@ Some methods return more data than can efficiently fit into one response. When t
|
||||
|
||||
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.
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
{% tabs %}
|
||||
|
||||
_Python_
|
||||
{% tab label="Python" %}
|
||||
{% code-snippet file="/_code-samples/markers-and-pagination/py/pagination-with-markers.py" language="py" /%}
|
||||
{% /tab %}
|
||||
|
||||
{{ include_code("_code-samples/markers-and-pagination/py/pagination-with-markers.py", language="py") }}
|
||||
{% tab label="JavaScript" %}
|
||||
{% code-snippet file="/_code-samples/markers-and-pagination/js/pagination-with-markers.js" language="js" /%}
|
||||
{% /tab %}
|
||||
|
||||
_JavaScript_
|
||||
|
||||
{{ include_code("_code-samples/markers-and-pagination/js/pagination-with-markers.js", language="js") }}
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
{% /tabs %}
|
||||
|
||||
@@ -9,9 +9,9 @@ labels:
|
||||
|
||||
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).
|
||||
**Tip:** Rate limiting does not apply when the client is connected [as an admin](../../../tutorials/get-started/get-started-using-http-websocket-apis.md#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.
|
||||
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.md). 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.
|
||||
|
||||
@@ -54,16 +54,13 @@ The usage rate drops off exponentially over time, so a client that does not make
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [The `rippled` Server](xrpl-servers.html)
|
||||
- [Software Ecosystem](software-ecosystem.html)
|
||||
- [The `rippled` Server](../../../concepts/networks-and-servers/index.md)
|
||||
- [Software Ecosystem](../../../introduction/software-ecosystem.md)
|
||||
- **Tutorials:**
|
||||
- [Getting Started with XRP Ledger APIs](get-started-using-http-websocket-apis.html)
|
||||
- [Troubleshooting rippled](troubleshoot-the-rippled-server.html)
|
||||
- [Getting Started with XRP Ledger APIs](../../../tutorials/get-started/get-started-using-http-websocket-apis.md)
|
||||
- [Troubleshooting rippled](../../../infrastructure/troubleshooting/index.md)
|
||||
- **References:**
|
||||
- [rippled API Reference](http-websocket-apis.html)
|
||||
- [Error Formatting](error-formatting.html)
|
||||
- [rippled API Reference](../index.md)
|
||||
- [Error Formatting](error-formatting.md)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -7,10 +7,9 @@ blurb: Standard request format, with examples, for the WebSocket, JSON-RPC, and
|
||||
|
||||
## Example Request
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
{% tabs %}
|
||||
|
||||
{% tab label="WebSocket" %}
|
||||
```json
|
||||
{
|
||||
"id": 2,
|
||||
@@ -21,9 +20,9 @@ blurb: Standard request format, with examples, for the WebSocket, JSON-RPC, and
|
||||
"api_version": 1
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
{% tab label="JSON-RPC" %}
|
||||
```json
|
||||
POST http://s1.ripple.com:51234/
|
||||
Content-Type: application/json
|
||||
@@ -40,14 +39,15 @@ Content-Type: application/json
|
||||
]
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
*Commandline*
|
||||
|
||||
{% tab label="Commandline" %}
|
||||
```sh
|
||||
rippled account_info r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 validated strict
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
{% /tabs %}
|
||||
|
||||
|
||||
## WebSocket Format
|
||||
@@ -56,12 +56,12 @@ After you open a WebSocket to the `rippled` server, you can send commands as a [
|
||||
|
||||
| Field | Type | Description |
|
||||
|:--------------------|:----------|:-------------------------------------------|
|
||||
| `command` | String | The name of the [API method](public-api-methods.html). |
|
||||
| `command` | String | The name of the [API method](../public-api-methods/index.md). |
|
||||
| `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][] |
|
||||
| `api_version` | Number | _(Optional)_ The API version to use. If omitted, use version 1. For details, see [API Versioning](#api-versioning). {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.5.0" %}New in: rippled 1.5.0{% /badge %} |
|
||||
| (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.
|
||||
See [Response Formatting](response-formatting.md) for the response from the server.
|
||||
|
||||
## JSON-RPC Format
|
||||
|
||||
@@ -76,7 +76,7 @@ Send request body as a [JSON](https://en.wikipedia.org/wiki/JSON) object with th
|
||||
|
||||
| Field | Type | Description |
|
||||
|:--------------------|:----------|:-------------------------------------------|
|
||||
| `method` | String | The name of the [API method](public-api-methods.html). |
|
||||
| `method` | String | The name of the [API method](../public-api-methods/index.md). |
|
||||
| `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:
|
||||
@@ -86,13 +86,13 @@ The object inside the `params` array can contain the following fields:
|
||||
| `api_version` | Number | _(Optional)_ The API version to use. If omitted, uses version `1`. For details, see [API Versioning](#api-versioning). |
|
||||
| (Method Parameters) | (Various) | Provide any parameters to the method here. |
|
||||
|
||||
See [Response Formatting](response-formatting.html) for the response from the server.
|
||||
See [Response Formatting](response-formatting.md) 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](commandline-usage.html#client-mode-options).
|
||||
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](../../../infrastructure/commandline-usage.md#client-mode-options).
|
||||
|
||||
The commandline calls JSON-RPC, so its responses always match the JSON-RPC [response format](response-formatting.html).
|
||||
The commandline calls JSON-RPC, so its responses always match the JSON-RPC [response format](response-formatting.md).
|
||||
|
||||
The commandline always uses the latest [API version](#api-versioning).
|
||||
|
||||
@@ -101,7 +101,7 @@ The commandline always uses the latest [API version](#api-versioning).
|
||||
|
||||
## API Versioning
|
||||
|
||||
The `rippled` server uses a single integer to identify the API version to use. Currently, there are two API versions: `1` and `2` [New in: rippled 2.0.0][]. The server reports the range of supported API versions in the `version` API method. <!-- STYLE_OVERRIDE: will --> <!-- TODO: add a link when `version` method is documented. -->
|
||||
The `rippled` server uses a single integer to identify the API version to use. Currently, there are two API versions: `1` and `2` {% badge href="https://github.com/XRPLF/rippled/releases/tag/2.0.0" %}New in: rippled 2.0.0{% /badge %}. The server reports the range of supported API versions in the `version` API method. <!-- STYLE_OVERRIDE: will --> <!-- TODO: add a link when `version` method is documented. -->
|
||||
|
||||
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 an `account_tx` request using API version 2 and then make another `account_tx` request using API version 1 from the same connection.
|
||||
|
||||
@@ -136,7 +136,4 @@ The following types of changes are **non-breaking changes** and may occur withou
|
||||
- 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' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -12,21 +12,20 @@ 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`. |
|
||||
| `status` | String | (WebSocket only) The value `success` indicates the request was successfully received and understood by the server. Some [client libraries](../../client-libraries.md) 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.md) omit this field on success. |
|
||||
| `type` | String | (WebSocket only) The value `response` indicates a direct response to an API request. [Asynchronous notifications](../public-api-methods/subscription-methods/subscribe.md) 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][] |
|
||||
| `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.md) 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). {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.5.0" %}New in: rippled 1.5.0{% /badge %} |
|
||||
| `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*
|
||||
{% tabs %}
|
||||
|
||||
{% tab label="WebSocket" %}
|
||||
```json
|
||||
{
|
||||
"id": 2,
|
||||
@@ -48,9 +47,9 @@ The fields of a successful response include:
|
||||
}
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
{% tab label="JSON-RPC" %}
|
||||
```json
|
||||
HTTP Status: 200 OK
|
||||
|
||||
@@ -72,8 +71,9 @@ HTTP Status: 200 OK
|
||||
}
|
||||
}
|
||||
```
|
||||
*Commandline*
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="Commandline" %}
|
||||
```json
|
||||
{
|
||||
"result": {
|
||||
@@ -93,8 +93,9 @@ HTTP Status: 200 OK
|
||||
}
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
{% /tabs %}
|
||||
|
||||
|
||||
## API Warnings
|
||||
@@ -126,9 +127,9 @@ Example warning:
|
||||
]
|
||||
```
|
||||
|
||||
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-servers), so you should [upgrade to the latest `rippled` version](install-rippled.html) as soon as possible. <!-- STYLE_OVERRIDE: will -->
|
||||
This warning indicates that the one or more [amendments](../../../concepts/networks-and-servers/amendments.md) 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](../../../concepts/networks-and-servers/amendments.md#amendment-blocked-servers), so you should [upgrade to the latest `rippled` version](../../../infrastructure/installation/index.md) 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).
|
||||
The server only sends this warning if the client is [connected as an admin](../../../tutorials/get-started/get-started-using-http-websocket-apis.md#admin-access).
|
||||
|
||||
This warning includes a `details` field with the following fields:
|
||||
|
||||
@@ -153,12 +154,12 @@ Example warning:
|
||||
]
|
||||
```
|
||||
|
||||
This warning indicates that the server is [amendment blocked](amendments.html#amendment-blocked-servers) and can no longer remain synced with the XRP Ledger.
|
||||
This warning indicates that the server is [amendment blocked](../../../concepts/networks-and-servers/amendments.md#amendment-blocked-servers) 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.
|
||||
The server administrator must [upgrade `rippled`](../../../infrastructure/installation/index.md) to a version that supports the activated amendments.
|
||||
|
||||
### 1003. This is a reporting server
|
||||
[New in: rippled 1.7.0][]
|
||||
{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.7.0" %}New in: rippled 1.7.0{% /badge %}
|
||||
|
||||
Example warning:
|
||||
|
||||
@@ -180,22 +181,18 @@ It is generally safe to ignore this warning.
|
||||
|
||||
## See Also
|
||||
|
||||
- [Request Formatting](request-formatting.html)
|
||||
- [Error Formatting](error-formatting.html) for unsuccessful API responses.
|
||||
- [Request Formatting](request-formatting.md)
|
||||
- [Error Formatting](error-formatting.md) for unsuccessful API responses.
|
||||
- **Concepts:**
|
||||
- [The `rippled` Server](xrpl-servers.html)
|
||||
- [Consensus](consensus.html)
|
||||
- [Amendments](amendments.html)
|
||||
- [Known Amendments](known-amendments.html)
|
||||
- [The `rippled` Server](../../../concepts/networks-and-servers/index.md)
|
||||
- [Consensus](../../../concepts/consensus-protocol/index.md)
|
||||
- [Amendments](../../../concepts/networks-and-servers/amendments.md)
|
||||
- [Known Amendments](../../../resources/known-amendments.md)
|
||||
- **Tutorials:**
|
||||
- [Get Started with XRP Ledger APIs](get-started-using-http-websocket-apis.html)
|
||||
- [Install and Update `rippled`](install-rippled.html)
|
||||
- [Get Started with XRP Ledger APIs](../../../tutorials/get-started/get-started-using-http-websocket-apis.md)
|
||||
- [Install and Update `rippled`](../../../infrastructure/installation/index.md)
|
||||
- **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' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -21,7 +21,4 @@ Depending on how the `rippled` server is configured, how long it has been runnin
|
||||
|
||||
**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' %}
|
||||
{% raw-partial file="/_snippets/common-links.md" /%}
|
||||
|
||||
Reference in New Issue
Block a user