From RippleWiki

Implementation: ClientAPI

Ripple Client Server Protocol/API

The interface between inter-user accounting clients and the Ripple backend, either standalone or distributed.

Ripple Merchant API

See how this component fits in the system

Requirements

A single Ripple server can support multiple clients.

A client instance can register and manage nodes and credit relationships between them.

A client can update data for nodes and credit relationships

Transaction interaction

Design

Two interfaces may be useful:

GET methods should generally have standard ways of filtering, sorting and limiting results.

JSON for parameters and results. (Maybe XML as well if a client wants?)

HTTP

RESTful principles, GET/POST. GET is idempotent, POST for state-changing methods.

XMPP

Use <iq/> get/set stanzas.

Access

We'll need to allow for and control remote access, probably in a similar way to a database server, by IP address and by user/password authentication (regular HTTP authentication). We might add PKI stuff (HTTPS) later.

To implement, we'll need to store client identites (IP address, user, password) in the database, as well as have a configuration option (command line/config file) for which policies to implement.

Method Specification

For each method, need to specify:

For GET methods, given parameters are for filtering results. Every GET method also has the following parameters:

Rippler Server API

Client interface for an account system to the Ripple transaction server.

Account system data will be defined manually by the Ripple server admin.

Users

Accounts

Exchanges

Payments

Payment fields

Account System API

Account systems must provide the following to the transaction module:

Accounts

Payments

Issues between standalone and distributed engines

Remote users

To support both local and remote user identification for the distributed server, local users are identified by username only, and remote users by their Ripple ID (user@ripplehost:port). Apps developed on the standalone server should support Ripple usernames in this format for forward compatibility to the distributed server.

Signed messages

The distributed server will store signed messages as part of each account history and payment. These are not available on the standalone server. Could just have optional JSON return fields for these where necessary, that are left empty by the standalone server. These are only useful for auditing, and aren't central to regular operations.

Future directions

Customizable routing policy

Let the client specify a callback URL or formula that takes available data at each hop and makes more complex decisions about where to route and what exchange rates to use.

An implementation proposal

https://ripplexchange.com/viewtopic.php?f=9&t=12#p71

Retrieved from http://ripple.ryanfugger.com/Implementation/ClientAPI
Page last modified on February 25, 2011, at 02:12 AM