NMControl, JSON-RPC, and REST
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
NMControl, JSON-RPC, and REST
So, the NMControl JSON-RPC implementation needs to be replaced, since it's custom code that we don't want to be responsible for maintaining. (I think it's already violating the HTTP spec in some places.) I think this would be an opportunity to replace it with a REST interface, similar to what we're doing for namecoind.
The Bottle implementations looks pretty nice, and does what we need as far as I can tell: http://bottlepy.org/docs/dev/index.html . This would also allow us to unify the web interface that Phelix has been working on, with the RPC API. Bottle is also reportedly pretty easy to use with HTTPS.
Thoughts on this?
The Bottle implementations looks pretty nice, and does what we need as far as I can tell: http://bottlepy.org/docs/dev/index.html . This would also allow us to unify the web interface that Phelix has been working on, with the RPC API. Bottle is also reportedly pretty easy to use with HTTPS.
Thoughts on this?
-
- Posts: 69
- Joined: Sun Nov 23, 2014 3:34 pm
- os: linux
Re: NMControl, JSON-RPC, and REST
Since we are considering full-blown web frameworks, I'll ask if you have considered Flask?
Flask looks very similar to Bottle from my perspective. The only difference I see from a cursory inspection is that Flask only supports jinja2 as its templating engine without a plugin. The hello world syntax appears almost the same.
Flask also seems to support HTTPS. See this.
You can read more about Flask: http://flask.pocoo.org/.
So I don't see much advantage to selecting one framework over the other. I just wanted to bring up Flask since I already have experience using it. I'm sure either framework will be able to handle working as an RPC server.
Flask looks very similar to Bottle from my perspective. The only difference I see from a cursory inspection is that Flask only supports jinja2 as its templating engine without a plugin. The hello world syntax appears almost the same.
Flask also seems to support HTTPS. See this.
You can read more about Flask: http://flask.pocoo.org/.
So I don't see much advantage to selecting one framework over the other. I just wanted to bring up Flask since I already have experience using it. I'm sure either framework will be able to handle working as an RPC server.
Re: NMControl, JSON-RPC, and REST
+1 for bottle. Flask consists of more than ten times the lines of code than bottle.
For my API server experiments I do use bottle, too.
btw: I think we should extract/create a reusable module "nameprocessing" to handle value imports and similar things in nmcontrol and everywhere else.
edit: For now I will simply use plugindata.py... maybe that is reusable already.
For my API server experiments I do use bottle, too.
btw: I think we should extract/create a reusable module "nameprocessing" to handle value imports and similar things in nmcontrol and everywhere else.
edit: For now I will simply use plugindata.py... maybe that is reusable already.
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: NMControl, JSON-RPC, and REST
I haven't any experience with either Bottle or Flask. From glancing at the websites it looks like Bottle has better support for Python3 (although they both support it). My vote is for Bottle, but since I have no experience, my vote carries minimal weight.
@phelix yes, the data plugin should be reusable for processing imports and stuff like that.
@phelix yes, the data plugin should be reusable for processing imports and stuff like that.
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: NMControl, JSON-RPC, and REST
I will start work on a Bottle plugin for NMControl.
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: NMControl, JSON-RPC, and REST
I have Bottle working as a proof of concept. What I'd like to do is make each API call available as both .txt and .json. Is it okay if I modify the various plugins to support both output formats for each API call? (I will preserve the existing RPC interface and avoid redundant code.)biolizard89 wrote:I will start work on a Bottle plugin for NMControl.
Re: NMControl, JSON-RPC, and REST
Could you give an example? I am not sure what you mean by .txt Also what is the overall benefit?biolizard89 wrote:I have Bottle working as a proof of concept. What I'd like to do is make each API call available as both .txt and .json. Is it okay if I modify the various plugins to support both output formats for each API call? (I will preserve the existing RPC interface and avoid redundant code.)biolizard89 wrote:I will start work on a Bottle plugin for NMControl.
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: NMControl, JSON-RPC, and REST
Actually, never mind on that one for now. I think I have a less intrusive way to do it.phelix wrote:Could you give an example? I am not sure what you mean by .txt Also what is the overall benefit?biolizard89 wrote:I have Bottle working as a proof of concept. What I'd like to do is make each API call available as both .txt and .json. Is it okay if I modify the various plugins to support both output formats for each API call? (I will preserve the existing RPC interface and avoid redundant code.)biolizard89 wrote:I will start work on a Bottle plugin for NMControl.
FWIW, the initial use case I was thinking of was to provide better error data for the JSON. For example, right now the RPC interface doesn't provide a machine-readable explanation of why a domain resolution failed; a JSON field could be returned that makes this accessible, e.g. an error code (for getIp4) of 1 might mean the name doesn't exist, 2 might mean the name isn't valid JSON, 3 might mean a nameserver couldn't be reached, etc. The .txt version would be essentially the same as it is now, where it only returns the requested data with no frills.
However, I think there are better ways of doing this that don't require as much messing with the code... so I think I'll just assume that all requests are asking for the same format, and worry about error codes later. (This is why we have peer review -- thanks for making me rethink this a bit!)
So, suggested example format:
http://127.0.0.2:8080/dns/getIp4/veclabs.bit.json
will return something like this on success, with an HTTP status indicating success:
["216.17.101.97"]
and something like this on failure, with an HTTP status indicating failure:
{"code": 1, "message": "Failed to connect to Namecoin"}
Is this acceptable?
Re: NMControl, JSON-RPC, and REST
Yeah, I think errors should also be returned as json. IIRC both namecoind and nmcontrol return an "error" field in the json.
This is a little similar, too: https://github.com/phelixnmc/nmcapi/blob/master/api.py Should also implement error codes.
This is a little similar, too: https://github.com/phelixnmc/nmcapi/blob/master/api.py Should also implement error codes.
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: NMControl, JSON-RPC, and REST
Which is preferable:phelix wrote:Yeah, I think errors should also be returned as json. IIRC both namecoind and nmcontrol return an "error" field in the json.
This is a little similar, too: https://github.com/phelixnmc/nmcapi/blob/master/api.py Should also implement error codes.
Code: Select all
["216.17.101.97"] // success
{"code": 1, "message": "Failed to connect to Namecoin"} // failure
Code: Select all
{"result": ["216.17.101.97"]} // success
{"error": {"code": 1, "message": "Failed to connect to Namecoin"} }// failure