HTTP API documentation not up to date.

[pibara]

With the release of 2.0.0, the HTTP API documentation for the stable version of FlureeDB seems to have become outdated. The replacement API's for the now removed /fsb/dbs /fdb/new-db and /fdb/delete-db dont have any documentation here, and they seem to have changed from their also undocumented versions in the 1.0 version of FlureeDB (that implemented a simple forward). It is possible other relevant API changes are missing in the HTTP API documentation as well.

This issue is currently blocking this aioflureedb issue, that in turn blocks this issue for the Fluree Schema Scenario Tool (fsst).

[pibara]

Described a possibly important aspect of the ledger creation API in this thread on discord:

https://discord.com/channels/896089675511508992/896089675511508995/1092740323068874835

It is currenlly unclear if 1.0.5 behaviour with respect to population of _auth can be or should be mirrored by7 a client using the 2.0.0 API.

[jdorety]

PR fluree/developers-site#40 should address this issue

[pibara]

Not sure if this is an 1.0->2.0 API change thing, but /new-ledger seems to by default have other behaviour with respect to how the _auth collection is populated.

Here is what happens when /new-ledger is invoked, signed with the key from default_private_key.txt :

Signing with: Tf5L8Fg4QezWbR1RdGCqc7JUam2HTzvmQJg
Signed POST: url = http://localhost:8090/fdb/new-ledger , 
  headers = {
    'Content-Type': 'application/json',
    'X-Fluree-Date': 'Tue, 11 Apr 2023 09:15:21 GMT',
    'Signature': 'keyId="na",
                       headers="(request-target) x-fluree-date digest",algorithm="ecdsa-sha256",
signature="1b30440220412523a546ff52215165aa0368d22015dfc4fe718e0c7bf1e4d7c5a51de4223c02200c7c629c17d1f43a2233bb1d146c283cb1a9801df869592282da84f1588ed419"',
                       'Digest': 'SHA-256=XhjT6h0ck1jnAEtF+poNrRCYTxH/O++R7r8n3fi5A+Q='
    } ,
    ssl_verify_disabled = False
  body =  {"ledger/id":"test20450/api-school-classes"}
Result:
"882ee6399f4e4c8371969a124f21ab96dbbd299728d552c7715a358c6b1e81b2"

2023-04-11 09:15:21,336 ESC[34mINFO ESC[0;39m ESC[37mf.d.l.txgroup.monitorESC[0;39m 
- Initializing new ledger: "test20450/api-school-classes" 
- {:cmd "{\"ledger\":\"test20450/api-school-classes\",
  \"owners\":[\"Tf39irqqHjjTg8YfbLsvECTxinjEjdGcZYJ\"],
  \"type\":\"new-ledger\",
  \"expire\":1681204551272,
  \"nonce\":1681204521272}",
  :sig "1c304402201db330af6036a15c0e443ee832bf998349ea79e9cf73d92aaa419d7a8c2fda0a0220308194ebcb2d3362ef4461df70f4c60cbd944cfeb555eaf0999a008ea66df641", :id "882ee6399f4e4c8371969a124f21ab96dbbd299728d552c7715a358c6b1e81b2", :ledger "test20450/api-school-classes"} -

The operation is signed with Tf5L8Fg4QezWbR1RdGCqc7JUam2HTzvmQJg, but the database is created with Tf39irqqHjjTg8YfbLsvECTxinjEjdGcZYJ as owner. In the 1.0.5 the owner would end up being the same as the one who signed.

If I look at the API documentation for JavaScript here, there is something about options and root that purposably defaults to "connection default account id".

My guess is that what constitutes "connection default account id" has changed from 1.05 to 2.0.0, and the root argument (in whatever way it should be added to the new-ledger API call) is no longer optional?

[pibara]

Tried assing options::root to the body, but this form isn't working. Maybe if adding options could be documented:

{
  "ledger/id":"test21846/api-school-classes",
  "options":{
    "root":[
      "TewxGBV5BoHcmTM62HK89wjuxiJSsgX8fTG"
    ]
  }
}

[pibara]

Pushed the two images to docker hub for reproducability. To reproduce the result of what seems to be an API change:

python3 -m pip install fsst --force
git clone https://github.com/pibara/fsst-demo.git
cd fsst-demo/demo1/

Then for the working v1.0.5:

fsst dockertest --tag v1 --debug --verbosefluree --linger

And for the not-working v2.0.0:

fsst dockertest --tag stable-broken --debug --verbosefluree --linger