mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-28 23:55:49 +00:00
Start applying spell-checking
This commit is contained in:
mDuo13
@@ -41,7 +41,7 @@ Some types of hash appear in API requests and responses. Others are only calcula
|
||||
| Unsigned Transaction (Single-signing) | N/A | `0x53545800` | `STX\0` |
|
||||
| Unsigned Transaction (Multi-signing) | N/A | `0x534D5400` | `SMT\0` |
|
||||
| Validation vote | N/A | `0x56414C00` | `VAL\0` |
|
||||
| Validator subkey authorization ("validator manifest") | N/A | `0x4D414E00` | `MAN\0` |
|
||||
| Validator manifest | N/A | `0x4D414E00` | `MAN\0` |
|
||||
|
||||
[ledger header]: ledger-header.html
|
||||
[SHAMapv2]: known-amendments.html#shamapv2
|
||||
@@ -93,7 +93,7 @@ XRP is specified as a string containing an integer number of "drops" of XRP, whe
|
||||
|
||||
"Amount": "13100000"
|
||||
|
||||
- **Issued Currency** - To specify an `Amount` field with a value of 13.1 FOO issued by or to rf1B...:
|
||||
- **Issued Currency** - To specify an `Amount` field with a value of 13.1 FOO issued by or to `rf1B...`:
|
||||
|
||||
"Amount": {
|
||||
"value": "13.1",
|
||||
|
||||
@@ -112,4 +112,4 @@ All methods can potentially return any of the following values for the `error` c
|
||||
* `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](rippled-api.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.
|
||||
* `wsTextRequired` - (WebSocket only) The request's [opcode](https://tools.ietf.org/html/rfc6455#section-5.2) is not text. <!-- SPELLING_IGNORE: opcode -->
|
||||
|
||||
@@ -60,11 +60,11 @@ See [Response Formatting](response-formatting.html) for the response from the se
|
||||
|
||||
## 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 v1.2. For security reasons, `rippled` _does not support_ SSL v3 or earlier.
|
||||
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.
|
||||
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:
|
||||
|
||||
|
||||
@@ -95,14 +95,14 @@ When you combine a field's type code and field code, you get the field's unique
|
||||
| | Type Code < 16 | Type Code >= 16 |
|
||||
|:-----------------|:------------------------------------------------------------------------------|:--|
|
||||
| **Field Code < 16** |  |  |
|
||||
| **Field Code >= 16** |  |  |
|
||||
| **Field Code >= 16** |  |  |
|
||||
|
||||
When decoding, you can tell how many bytes the field ID is by which bits **of the first byte** are zeroes. This corresponds to the cases in the above table:
|
||||
|
||||
| | High 4 bits are nonzero | High 4 bits are zero |
|
||||
|:-----------------|:------------------------------------------------------------------------------|:--|
|
||||
| **Low 4 bits are nonzero** | 1 byte: high 4 bits define type; low 4 bits define field. | 2 bytes: low 4 bits of the first byte define field; next byte defines type |
|
||||
| **Low 4 bits are zero** | 2 bytes: high 4 bits of the first byte define type; low 4 bits of first byte are 0; next byte defines field | 3 bytes: first byte is 0x00, second byte defines type; third byte defines field |
|
||||
| **Low 4 bits are zero** | 2 bytes: high 4 bits of the first byte define type; low 4 bits of first byte are 0; next byte defines field | 3 bytes: first byte is `0x00`, second byte defines type; third byte defines field |
|
||||
|
||||
**Caution:** Even though the Field ID consists of the two elements that are used to sort fields, you should not sort by the serialized Field ID itself, because the byte structure of the Field ID changes the sort order.
|
||||
|
||||
@@ -342,6 +342,7 @@ When representing these fields in JSON objects, most are represented as JSON num
|
||||
|
||||
Another special case is the `TransactionType` field. In JSON, this field is conventionally represented as a string with the name of the transaction type, but in binary, this field is a UInt16. The `TRANSACTION_TYPES` object in the [definitions file](#definitions-file) maps these strings to specific numeric values.
|
||||
|
||||
<!-- SPELLING_IGNORE: pathset, stobject, starray, ledgerentry, vector256, accountids, uint -->
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
|
||||
Reference in New Issue
Block a user