[wildfly-dev] access to mgmt api/services

[Jason Greene]

BTW the reason I am complaining is because most of the time I have to GUESS what you are actually complaining about. Like is it the fact that you want reads to be more “REST” like?

Well you can do normal GETs if you want:
http://localhost:9990/management/host/master/server/server-one

and then parse the JSON for a server-state key

Or you could just do

http://localhost:9990/management/host/master/server/server-one?operation=attribute&name=server-state

Now REST is totally subjective, and some will say "OH THATS NOT REST ENOUGH". We could support anything really, we have a model and mostly data oriented operations, but because we also have to support things that can’t be modeled as data in a straightforward and intuitive way (e.g transactions), the API is mostly RPC oriented.

Of course saying all of this might have been a complete waste of my time because I have no idea if that’s what your little sarcastic barb was even about. 

On Feb 6, 2014, at 2:12 PM, Jason Greene <jason.greene at redhat.com> wrote:

> No but I would like to see a realistic proposal from you instead of your typical non-informed rants. 
> 
> On Feb 6, 2014, at 12:48 PM, Bill Burke <bburke at redhat.com> wrote:
> 
>> Lol.  Sure.  You want non Wildfly servers to standardize on:
>> 
>> {"operation":"read-attribute","address":[{"host":"master"},{"server":"server-01"}],"name":"server-state","json.pretty":1}'
>> 
>> Nope...  Still doesn't solve client initiated registration.
>> 
>> On 2/6/2014 11:01 AM, Jason Greene wrote:
>>> Is JSON not usable by non-Wildfly servers?
>>> 
>>> On Feb 6, 2014, at 9:55 AM, Bill Burke <bburke at redhat.com> wrote:
>>> 
>>>> We already have a keycloak subsystem.  Again, the issue is, the Wildfly mgmt REST interface is Wildfly specific, with Wildfly peculiarities, using wildfly specific envelope formats.  Not very useful for non-wildfly servers. :)
>>>> 
>>>> This isn't just Keycloak though.  OpenID Connect has a registration REST API which is client driven and not IDP driven.
>>>> 
>>>> On 2/6/2014 10:38 AM, Tomaž Cerar wrote:
>>>>> Maybe it is really time to write keycloak subsystem, that way you will
>>>>> be able to expose also keycloak config via rest (and other mechanism)
>>>>> 
>>>>> --
>>>>> tomaz
>>>>> 
>>>> 
>>>>>   Yet another reason is that it would be cool if there were a unified,
>>>>>   common REST API that the Keycloak admin console could use to manage and
>>>>>   talk to server instances that want to join or be managed by a Keycloak
>>>>>   realm.  Without this common REST API, we would have to write a Keycloak
>>>>>   server adapter (and UI screens) to handle them, which would mean that
>>>>>   the Keycloak server would probably have to be shut down too to install
>>>>>   any new adapter.
>>>>> 
>>>>>   The OP asked how to get access, locally, to mgmt api/services.  Brian's
>>>>>   response was, "just use the HTTP interface".  I now have 2 reasons why
>>>>>   "just use the HTTP interface" may not be feasible.
>>>>> 
>>>> 
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>> 
>>> --
>>> Jason T. Greene
>>> WildFly Lead / JBoss EAP Platform Architect
>>> JBoss, a division of Red Hat
>>> 
>> 
>> -- 
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
> 
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat