ARCHIVE/rippled
1
0
Fork 0
mirror of https://github.com/XRPLF/rippled.git synced 2025-11-04 11:15:56 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
aded4a7a925a5822522e6bbbb4adfd3fec39257b
rippled/API-CHANGELOG.md
Elliot Lee aded4a7a92 docs: add API Changelog (#4612) 
Introduce an API Changelog, which logs the changes that have been made
to the API.

Without this changelog, it is difficult to keep track of the changes and
additions that are made to the API. While all changes are surfaced in
PRs and Release Notes, these are mixed in with other non-API-affecting
changes. PRs that affect the API have the `API Change` label applied,
but it is hard to identify which PRs have been included in each release.
Furthermore, some API changes will take effect based on `api_version`
(starting with rippled version 1.12, which will introduce `api_version:
2`), while others are based on the `rippled` version.

The API Changelog clarifies the details of the changes in a way that is
easily understood by API consumers, and breaks down the changes to be
clear which ones are gated by api_version (versus `rippled` version).

From now on, all PR authors are responsible for updating the API
Changelog according to the additions/changes that their PR makes to the
APIs.
2023-07-19 14:03:26 -07:00

7.0 KiB
Raw Blame History

API Changelog

This changelog is intended to list all updates to the API.

For info about how API versioning works, view the XLS-22d spec. For details about the implementation of API versioning, view the implementation PR.

The API version controls the API behavior you see. This includes what properties you see in responses, what parameters you're permitted to send in requests, and so on. You specify the API version in each of your requests. When a breaking change is introduced to the rippled API, a new version is released. To avoid breaking your code, you should set (or increase) your version when you're ready to upgrade.

For a log of breaking changes, see the API Version [number] headings. Breaking changes are associated with a particular API Version number. For non-breaking changes, scroll to the XRP Ledger version [x.y.z] headings. Non-breaking changes are associated with a particular XRP Ledger (rippled) release.

API Version 2

This version will be supported by rippled version 1.12.

V2 account_info response

signer_lists is returned in the root of the response, instead of being nested under account_data (as it was in API version 1). (#3770)

API Version 1

This version is supported by rippled version 1.11.

Idiosyncrasies

V1 account_info response

In the response to the account_info command, there is account_data - which is supposed to be an AccountRoot object - and signer_lists is in this object. However, the docs say that signer_lists should be at the root level of the reponse - and this makes sense, since signer lists are not part of the AccountRoot object. (First reported in xrpl-dev-portal#938.) Thanks to rippled#3770, this field will be moved in api_version: 2, to the root level of the response.

server_info - network_id

The network_id field was added in the server_info response in version 1.5.0 (2019), but it was not returned in reporting mode.

XRP Ledger version 1.12.0

Version 1.12.0 is in development.

Additions in 1.12

Additions are intended to be non-breaking (because they are purely additive).

  • server_info: Added ports, an array which advertises the RPC and WebSocket ports. This information is also included in the /crawl endpoint (which calls server_info internally). grpc and peer ports are also included. (https://github.com/XRPLF/rippled/pull/4427)
    • ports contains objects, each containing a port for the listening port (a number string), and a protocol array listing the supported protocols on that port.
    • This allows crawlers to build a more detailed topology without needing to port-scan nodes.
    • (For peers and other non-admin clients, the info about admin ports is excluded.)
  • Clawback: The following additions are gated by the Clawback amendment (featureClawback). (https://github.com/XRPLF/rippled/pull/4553)
    • Adds an AccountRoot flag called lsfAllowTrustLineClawback (https://github.com/XRPLF/rippled/pull/4617)
      • Adds the corresponding asfAllowTrustLineClawback AccountSet Flag as well.
      • Clawback is disabled by default, so if an issuer desires the ability to claw back funds, they must use an AccountSet transaction to set the AllowTrustLineClawback flag. They must do this before creating any trust lines, offers, escrows, payment channels, or checks.
    • Adds the Clawback transaction type, containing these fields:
      • Account: The issuer of the asset being clawed back. Must also be the sender of the transaction.
      • Amount: The amount being clawed back, with the Amount.issuer being the token holder's address.

XRP Ledger version 1.11.0

Version 1.11.0 was released on Jun 20, 2023.

Breaking changes in 1.11

  • Added the ability to mark amendments as obsolete. For the feature admin API, there is a new possible value for the vetoed field. (#4291)
  • The API now won't accept seeds or public keys in place of account addresses. (#4404)
  • For the ledger_data method, when all entries are filtered out, the API now returns an empty list (an empty array, []). (Previously, it would return null.) While this is technically a breaking change, the new behavior is consistent with the documentation, so this is considered only a bug fix. (#4398)
  • If and when the fixNFTokenRemint amendment activates, there will be a new AccountRoot field, FirstNFTSequence. This field is set to the current account sequence when the account issues their first NFT. If an account has not issued any NFTs, then the field is not set. (#4406)
    • There is a new account deletion restriction: an account can only be deleted if FirstNFTSequence + MintedNFTokens + 256 is less than the current ledger sequence.
    • This is potentially a breaking change if clients have logic for determining whether an account can be deleted.
  • NetworkID
    • For sidechains and networks with a network ID greater than 1024, there is a new transaction common field, NetworkID. (https://github.com/XRPLF/rippled/pull/4370)
      • This field helps to prevent replay attacks and is now required for chains whose network ID is 1025 or higher.
      • The field must be omitted for Mainnet, so there is no change for Mainnet users.
    • There are three new local error codes:
      • telNETWORK_ID_MAKES_TX_NON_CANONICAL: a NetworkID is present but the chain's network ID is less than 1025. Remove the field from the transaction, and try again.
      • telREQUIRES_NETWORK_ID: a NetworkID is required, but is not present. Add the field to the transaction, and try again.
      • telWRONG_NETWORK: a NetworkID is specified, but it is for a different network. Submit the transaction to a different server which is connected to the correct network.

Additions and bug fixes in 1.11