Rest api's transactional

Other Northbound Interfaces
1

We were playing with the REST api’s using candidate+running DB and we wanted to know the behavior of REST vs CLI in multi-user environment.

In CLI, if 2 users A and B are working at the same time, before commit, no one is going to see each work(cli commands) uncommitted stuff and commit of user A will not commit the cli commands of user B.
Does it mean even though cli commands are going to candidate DB, they still maintain small private candidate DB for uncommitted work?

Whereas in REST, if 2 users A and B are working at the same time, commit performed by user A will commit the whole candidate DB? So we don’t maintain the multi-user support in REST??
I know JSON-RPC works exactly like CLI, but why is the REST behavior different. (I understand that each REST is a commit of itself but why REST on candidate DB wait till _commit REST command to perform final commit?

Please let us know are we are deciding between using REST vs JSON-RPC.

Also we found below description in the user-guide. Will it help in our case?

Sending REST requests using a browser is an easy way to test things. But using REST with Basic Authentication in the browser should not be used because of security considerations. Use the JSON-RPC login mechanism instead. Once authenticated, REST requests don’t need Basic Authentication anymore. You can read more about the JSON login mechanism in ???.

AND
The transaction Resource

The “transaction” resource represents a transaction datastore created by the JSON-RPC API. This allows REST API requests that read or write towards an existing transaction, without committing the transaction (this is left up to other entities e.g. the JSON-RPC API).

The media type of this resource is either “application/vnd.yang.datastore+xml” or “application/vnd.yang.datastore+json”.

=====

So in our case, if we let user login using the jsonrpc and use the sessionToken for the REST api’s (different token per user login). Then their REST api’s will end towards transaction resource and only on _commit, it will go to candidate then running? This looks like solving our case of multi-user environment where each user has its own session view.

Please confirm.

Thanks,
-gopal

2

Gopal,

REST is stateless so we can’t expect from REST to behave like a CLI session for example. I think you already understand that since you mentioned using JSON-RPC to establish the session and therefor maintain a state.

You can definitely go this route and use a combined approach where you use JSON-RPC for authentication and creation of the transaction then REST for writing to the candidate datastore which you have to commit using JSON-RPC again.

The candidate you are referring to when talking about CLI is a copy of the running if the running is writable (This is configurable in confd.conf) or it becomes a diff if the running is in a writable-through-candidate mode (Configurable in confd.conf): This is the ideal combination if using a running and a candidate datastore.

There is only one candidate datastore that is enabled by supporting the NETCONF capability :candidate. It is then important to understand how ConfD behaves when a write transaction is initiated, in different configuration scenarios. Take a look at the snippet, from the user guide (This is the JSON-RPC API you would use to start a transaction):

19.17.2. Method new_trans

Params:
{“db”: <“startup” | “running” | “candidate”, default: “running”>,
“mode”: <“read” | “read_write”, default: “read”>,
“conf_mode”: <“private” | “shared” | “exclusive”, default: “private”>,
“tag”: ,
“th”: }

private (writable running enabled) - Edit a private copy of the running configuration, no lock is taken.

private (writable running disabled, startup enabled) - Edit a private copy of the startup configuration, no lock is taken.

exclusive (candidate enabled) - Lock the running configuration and the candidate configuration and edit the candidate configuration.

exclusive (candidate disabled, startup enabled) - Lock the running configuration (if enabled) and the startup configuration and edit the startup configuration.

shared (writable running enabled, candidate enabled) - Edit the candidate configuration without locking it.

So it depends on what you enable in your system the behavior will be different to insure that multiple users can configure the system in parallel.

So, to answer your question more directly, on commit of the transaction, the candidate will be copied to the running. Depending on how you started the transactions (Private, exclusive or shared) the commit will result in a different running: In the case of shared for example, you will be committing other users’ changes to the candidate as well. This is a wanted behavior in some cases.

In any case, you are in control at the time you start the transaction. If you don’t want the Shared behavior then use private or exclusive and you should be good to go.

3

Could you give examples where 2 REST clients login (same username) then create their local transaction using new_trans. And when the 1st rest client does some changes towards candidate db its not visible to 2nd rest client?
And then when the 1st rest client does _commit on candidatedb, it gets visible to 2nd rest client too?

I am having issue because below is my observation:

  1. Login: http://10.150.11.7:8008/jsonrpc
    { “jsonrpc”: “2.0”, “id”: 25, “method”: “login”, “params”: { “user”: “admin”,“passwd”:“admin”}}

  2. Create new_trans: http://10.150.11.7:8008/jsonrpc
    {
    “jsonrpc”: “2.0”,
    “id”: 25,
    “method”: “new_trans”,
    “params”: {
    “db”: “candidate”,
    “mode”: “read_write”,
    “conf_mode”: “private”
    }
    }
    ===Followed 1st 2 steps with different ID’s with 2 different rest-clients (got 2 different cookies)

  3. Then start issuing REST api’s towards candidate DB using 1st REST client.
    Somehow REST client 2 gets to see the value changed by rest client1 and cookies returned to client 2 becomes same as cookie returned to rest client 1.