search

SpriteLink / NIPAP

Neat IP Address Planner - NIPAP is the best open source IPAM in the known universe, challenging classical IP address management (IPAM) systems in many areas.
https://spritelink.github.io/NIPAP/
MIT License
524 stars 132 forks source link

Add REST API #570

Open plajjan opened 9 years ago

plajjan commented 9 years ago

I would like to add a REST API to nipapd.

REST is the hottest thing on the block right now, so it's only natural we go with the hype and replace our XML-RPC API with a fancy new REST API ;) Seriously though, it does have some nice benefits.

My idea is to add the REST API as an experimental API for the time being. Having it marked as experimental means that we can change stuff along the way and I think it will take a number of releases to pin this one down. Naturally, the REST API should have versioning unlike our current XML-RPC API. That will make changing things in the future A LOT easier.

There are a few other changes that are coming up that might mean some serious changes to the API, so by adding REST API we can do the changes there and do what we can to have the XML-RPC be backwards compatible towards old clients (or should we care?). One such change is the relaxation of assignment / hosts check, tracked in #530. Further, pynipap should be refactored to avoid having the connection be a singleton and instead "inject" it where appropriate. For example, today it is not possible to connect to two nipapd instances at the same time, since the connection is a singleton. We currently have caching in pynipap, which can be turned off as a global option. Instead I would like to have wrapper classes that perform the actual caching.. all of this can be done through some refactoring but it will be very difficult to maintain backwards compatibility. REST API fits in nicely with that.

The web UI currently has a xhr class that pretty much translates between the XML-RPC API and web friendly JSON. It dumbs down some of the arguments to XML-RPC as some are difficult to express with the currenty way we do things in the web UI. As we progress in our transition towards Angular JS, I imagine that we instead can interface directly to the REST API instead of going through our xhr class methods. It will remove some processing latency and above all remove code. Now, the REST API (which is basically served by a small web server) will not serve the web UI. Either the REST API listens on a different port than the web UI (80 & 443), or the web server (e.g. Apache) is set up to proxy a URL to the REST API, like /api goes to the REST API. That way we can also achieve the frontend / backend split that we currently have while still allowing clients to only talk to the frontend address.

So, goal for this issue is adding the framework for a REST API that can run in parallel with the XML-RPC interface.

See http://flask-restful.readthedocs.org/en/latest/intermediate-usage.html

plajjan commented 9 years ago

Also see comment in #599 on datetime conversion. Hopefully some JSON-RPC lib will solve this for us.

thvxl commented 3 years ago

Hey, is this feature something you're working on? I'd be more than happy to help implement this if there's interest. 🙂

garberg commented 3 years ago

Since quite recently, yes it is (again). A partial implementation very much like the XML-RPC-API should emerge in a reasonably near future (a few weeks or so). When it appears we'd be happy to receive some help with extending the functionality!

thvxl commented 3 years ago

@garberg More than happy to help! :) Is there a possibility to get notified when that's implemented? If not I'll just keep a close eye on the repo :)