@@ -84,7 +84,7 @@ The server configuration file looks like this:
log_file= <string>
```
**NOTE**: **CORS** and **TLS** are not yet fully implemented, and cannot be used. It is unlikely that it will be supported before `1.0`. CORS will be implemented through [gin middleware](https://github.com/tommy351/gin-cors), and TLS through the standard Go http package via the [graceful library](https://github.com/tylerb/graceful).
**NOTE**: **CORS** and **TLS** are not yet fully implemented, and cannot be used. CORS is implemented through [gin middleware](https://github.com/tommy351/gin-cors), and TLS through the standard Go http package via the [graceful library](https://github.com/tylerb/graceful).
##### Bind
...
...
@@ -155,7 +155,7 @@ log_file=""
The library includes a "server-server". This server accepts POST requests with some chain data (such as priv_validator.json and genesis.json), and will use that to create a new working directory in the temp folder, write the data, deploy a new node in that folder, generate a port, use it to serve that node and then pass the url back in the response. It will also manage all the servers and shut them down as they become inactive.
NOTE: This is not safe in production, as it requires private keys to be passed over a network, but it is very useful when doing tests. If the same chain data is used, then each node is guaranteed to give the same output (for the same input) when calling the methods.
NOTE: This is not safe in production, as it requires private keys to be passed over a network, but it is useful when doing tests. If the same chain data is used, then each node is guaranteed to give the same output (for the same input) when calling the methods.
To start one up, just run `go install` in the `erisdb/cmd/erisdbss` directory, then run `erisdbss`. It takes no parameters. There are many examples on how to call it in the javascript library, and if people find it useful there will be a tutorial.
...
...
@@ -167,7 +167,7 @@ Run using `go test` as usual. There are 3 tiers of tests:
* Tier 2 is a full client-server test of `erisdb` using a mock implementation of the [Pipe](https://github.com/eris-ltd/erisdb/blob/master/erisdb/pipe/pipe.go).
* Tier 3 is a full client-server test of `erisdb` using a live node.
Eris DB allows remote access to its functionality over http and websocket. It currently supports JSON-RPC, and REST-like http. There is also javascript bindings available in the [erisdb-js](TODO) library.
...
...
@@ -90,8 +92,7 @@ Response:
<aname="rest-like"></a>
## REST-like HTTP
The REST-like API provides the typical endpoint structure i.e. endpoints are resources, parameters can be put in the path, and queries are used only for filtering. It is not fully compatible with REST; partly because some GET requests can contain sizable input so POST is used instead. There are also some modeling issues but those will most likely be resolved before version 1.0.
The REST-like API provides the typical endpoint structure i.e. endpoints are named as resources, parameters can be put in the path, and queries are used for filtering and such. It is not fully compatible with REST; partly because some GET requests can contain sizable input so POST is used instead. There are also some modeling issues but those will most likely be resolved before version 1.0.
<aname="formatting-conventions"></a>
##Common objects and formatting
...
...
@@ -102,7 +103,7 @@ This section contains some common objects and explanations of how they work.
Numbers are always numbers, and never strings. This is different from Ethereum where currency values are so high they need string representations. The only thing hex strings are used for is to represent byte arrays.
Hex strings are never prefixed.
Hex strings are never prefixed.
#####Examples
...
...
@@ -404,7 +405,7 @@ Event object:
##Methods
###Accounts
| Name | RPC method name | REST method | REST endpoint |
| Name | RPC method name | HTTP method | HTTP endpoint |
