Provide a REST API

[mpreisler]

We already provide a dbus API but some prospective users would strongly prefer a REST API. We should refactor the System and DBusDaemon classes so that we can run one service that exposes 2 APIs at the same time.

[mvazquezc]

Hi!,

I've written a Python API using flask on top of your daemon, maybe it can be integrated somehow.

https://github.com/mvazquezc/oscap-daemon-api

[mpreisler]

Hi @mvazquezc. Your project looks great, would you be interested in refactoring it and submitting it as a pull request here? I think we could refactor the code so that dbus and REST APIs can be used in any combination, depending on config.ini.

Could you please relicense your code as LGPL? I can't change the license of this project.

[mvazquezc]

Sure! It will take me some time but I'll send a PR as soon as I have the new implementation coded.

[naltun]

Hey guys. Is providing a REST API still planned, or has it been put to rest?

I wasn't aware of the dbus API, so I'll take a look at that. Having a REST API would be awesome, though. Also, I'm taking a look at @mvazquezc's oscap-daemon-api. Pretty nifty. I'll have to test that at some point.

[jan-cerny]

@naltun I agree that a REST API would be awesome. However, I think it is still just an idea.

[naltun]

@jan-cerny I've never hacked onto OpenSCAP (nor OpenSCAP Daemon), but if I can help out with the REST API, I'd be happy to help.

[rshade]

I have been using @mvazquezc openscap api, and its great. It seems to have all the requisite features and the report and guide are awesome.

[naltun]

Can OpenSCAP fork and test the project, and manage their own version? Is this a potential option?

[mpreisler]

Can OpenSCAP fork and test the project, and manage their own version? Is this a potential option?

Definitely an option. We all have time constraints though. If you want to make it very likely that we will integrate this into openscap-daemon please feel free to submit a PR yourself. Waiting for somebody else might also sometimes work but it has been two years :-)

[rshade]

@mpreisler would you be willing to make us a feature branch to work off of, so we can sync many disparate forks?

[rshade]

Also can we setup a wiki for design ideas. My first initial move would be to dump @mvazquezc code in there once he changes the license out and approves it, but we would need to discuss how openscap-daemon will serve http requests.

[mvazquezc]

I've changed the license to use the same licenses as OpenScap Daemon.

I just took a look at this a few days ago. I've done some changes to the daemon to read the API config from the config file.

We can migrate the main class and just use the method defined on the OpenScap daemon (there is no need to talk with the DBUS daemon anymore, correct me if I'm wrong though.)

I'm willing to help with this feature, if you set up a new branch I could commit my changes there.

[mpreisler]

We can migrate the main class and just use the method defined on the OpenScap daemon (there is no need to talk with the DBUS daemon anymore, correct me if I'm wrong though.)

Agreed, there shouldn't be any need to talk REST to dbus to daemon API, REST can talk directly to the API.

[mpreisler]

I'm willing to help with this feature, if you set up a new branch I could commit my changes there.

just for public record, I gave @mvazquezc write access to the repo. I think doing those changes in a separate branch and then merging into master after things stabilize is the way to go.