Xn-cli NPM | npm.io

xn CLI Tool

Fast and easy utilities for the XN Logic graph database application framework's REST API.

Overview

Execute calls against the XN REST API, with various commands for good measure.

Basic usage:

    xn --token $LMTOKEN -p 8080 get account

Note that the leading slash was not required for /account. Several other options are available: --https --host --port --api-prefix for basic config, --token "a token" or --admin or --db db_name to provide authentication. Note that --admin will only work if an admin_token exists in /opt/xn_apps (ie. only on the box running the API server). Also, --db will use --admin to do its initial token query, but you can override that by specifying an admin token with --token.

Profiles

   xn --token $LMTOKEN -p 8080 save-profile user_x
   xn user_x get account

Profiles should make it simple to manage multiple servers / vms. You can also list all profiles, show and delete them. They're easy to hand-craft in ~/.xn if you like, too. If you save a profile with an existing name, the old one will be replaced.

  xn profiles
  xn profiles --show user_x
  xn profiles --delete user_x

Multiple requests in one command

Not sure if this is useful:

  xn user_x get /is/vm /is/server
  xn user_x patch /is/vm/id/1 '{"name":"VM1"}' /is/vm/id/2 '{"name":"VM2"}'
  xn user_x delete /is/vm/id/{1,2}

Flexible post data

  xn user_x patch /is/vm/id/1 -f path/to/data.json
  xn user_x patch /is/vm/id/2 --mime application/transit+json -f /path/to/data.transit

Or even combined in statement:

  xn user_x patch /is/vm/id/1 -f path/to/data /is/vm/id/2 --mime application/transit+json -f /path/to/data.transit

Examples

Configure and use the API from the dev VM's host

This workflow is super painful with the old tools:

First, in the VM, get the client's admin token. Here the client is called "dev". This relies on the presence of /opt/xn_apps/admin_token, which is created at server boot. No prior setup is required.

$ xn --db dev token
dev v5o9VnyABpmoP2bi1mVd

Alternatively we could also get the admin token with xn --admin token.

That's it on the VM. Now, we'll create a profile on the host to use this token. We could also make requests directly with token in the arguments, but here we perhaps need it longer-term. Note that the xn script is on the path in both the host and the VM.

$ xn --token 'dev v5o9VnyABpmoP2bi1mVd' -h 192.168.168.168 save-profile vm_dev

And a quick test that it works:

$ xn vm_dev get --raw account
[{"meta":{"xnid":"/model/user_account/id/51","model_name":"user_account", ....

The profile configuration is saved ~/.xn:

$ cat ~/.xn
{
   "vm_dev": {
       "host": "192.168.168.168",
       "port": 80,
       "url-prefix": "/v1",
       "token": "dev v5o9VnyABpmoP2bi1mVd"
   }
}

The config file may have settings from multiple servers, simply create each with a different name.

Using a profile as a base

The profile we defined above worked on port 80. If I were having problems with Nginx, I could try out the same request over port 8080 like this:

$ xn vm_dev -p 8080 get --raw /is
["data_source","external_record","group","import","import_record","job","m","note","part","permission","record","token","transaction_detail","user"]