Functionality supported via: console vs. REST API vs. command line API ?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
Report Content as Inappropriate

Functionality supported via: console vs. REST API vs. command line API ?

My apologies in advance if the answer to this question is documented somewhere, but we can't find the answer, and it is not clear to my team . . .

We're using glu for one of our projects, and we want to add several (non-trivial) pieces of our own functionality to it. It looks like our candidate ways of integrating with glu are: 1) Add our own functionality to the glu console; 2) Create a web app. of our own (to replace the console and add our functionality), and integrate with glu via the REST API; and 3) Create our own web app. (as in 2), but integrate with glu via the command line API.

However, a previous forum posting, http://glu.977617.n3.nabble.com/About-Glu-Console-tp4026430p4026433.html, says (in part): "There are obviously quite a few REST api missing . . ."

So, our concern/question is: if we integrate with glu via the REST API (#2, above), what glu functionality would not be available to us. Same question for integration via the command line API (#3, above) -- what functionality would not be available to us. Or, put another way, does the glu web app have access to or expose functionality that is not available via the REST API, or via the command line API? Note, by "functionality", I mostly mean the services and business logic that glu supports, though obviously there are nice bits of UI/presentation functionality that the glu console adds.

Thanks in advance,
Black Duck Software
Jim Abbott
Reply | Threaded
Open this post in threaded view
Report Content as Inappropriate

Re: Functionality supported via: console vs. REST API vs. command line API ?

Hello Jim

This list is exhaustive and shows everything that can be done via the REST api.

The command line exposes a subset of this REST api for 2 primary reasons:
1) the cli was mostly built as a proof of concept that you can talk to glu outside of glu using a non Java language
2) give an example of how to invoke the rest calls

The cli does not have the latest and greatest REST api calls simply because I am not a python guru and nobody has been contributing to it, meaning the latest REST api additions (like audit log) are not available via the cli. But it still serves its demo purpose.

In your case I would definitely advise to use the REST api directly.

I do realize that this does not answer your primary question which is what you can and cannot do with the REST api. I do not have the answer right out of my head. One obvious missing piece is user management (like adding new users, changing their role, etc...).

I do strongly believe that the REST api should allow you to do whatever the console lets you do. At this stage if there are missing features that you need, the best is to report them (ex: the audit log was not available via REST api and was added after a request) or even better submit a pull request :)

There is also something else to keep in mind: the way the console is built and deployed right now is as a single grails application. This means that the REST api and the Web GUI are actually living in the same instance. Or in other words, if you use the REST api, then the web gui is also available. This gives you the ability to still use the normal Web GUI in the event there is something you really need to do. I do understand that this is not convenient and would be inappropriate for normal users. But let's say you needed to change the password of a user, your glu admin could use the regular glu webapp to do so while waiting for the feature to be available as a REST api...

A few final comments: in this forum response: http://glu.977617.n3.nabble.com/About-Glu-Console-tp4026430p4026433.html I describe the various ways you can use to implement your own functionalities => I would strongly encourage you to see if there is another way than building your own on top of the REST api. If you are willing to share your requirements maybe I can help you figure out which path is the best for your use cases (you can do so privately if you are not comfortable sharing in the forum).

Hope this helps