[keycloak-dev] What to do about Java admin client

[Stian Thorgersen]

On 5 April 2016 at 12:31, Guus der Kinderen <guus.der.kinderen at gmail.com>
wrote:

> Hi Stian,
>
> First off: I didn't know that Keycloak existed three weeks ago. Much of
> what I write might be a result of me being unfamiliar with earlier design
> choices. That being said:
>
> Based on the snippet that you provided I'd argue that it is the service,
> rather than the admin client, that could/should be improved. When
> implementing a (REST) service, it is common to provide a representation as
> part of the response to a create (POST) request: the service response
> should include the most up-to-date representation of the resource, which
> prevents the client from having to reconstruct it (exactly what you're
> doing in that snippet), which is tedious, error-prone and lacking the
> inclusion of server-generated values. On top of that, if a client needs
> multiple requests to recreate a representation, concurrency issues come in
> to play. Who's to say that all responses reflect the exact same state,
> server sided?
>

I did take an extreme example and you're right that it can be improved by
fixing the server side rest endpoints.


>
> Restructuring the web services could lead to a large change (although
> inclusion of representation in responses might be backwards compatible, as
> the random sample of services that I checked appear to currently have empty
> responses - perhaps the representation could simply 'fit in'). In any case,
> timing-wise, such an effort would coincide with the upcoming 2.0
> development.
>

We have been discussing to introduce a version 2.0 of the rest api, we'd
still keep version 1 for backwards compatibility for a while at least.


>
> Based on the above, my suggestion would be:
> 1) Apart from the changes above, there might not be a need to rewrite the
> admin client. From my basic use over the last two weeks, I like it's
> simplicity. It provides a low-level entry point for people that start with
> Keycloak, which is good.
>

Maybe you're right and the client will be simpler to use once we improve
the server side


> 2) I can't say - simply don't have enough experience in this fields. Then
> again, in Java, when one says "in theory, it's compatible" it typically
> isn't.
>

;)


> 3) Apply the changes for the as-is client to 1.9.x, and improve services
> (and as a result, the client) in 2.x
>
> Kind regards,
>
>   Guus
>
>
> On 5 April 2016 at 10:19, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>> At least personally I think the admin client needs some TLC. For example
>> creating a user requires:
>>
>>         UserRepresentation user = new UserRepresentation();
>>         user.setUsername("user");
>>
>>         Response response = keycloak.realm("realm").users().create(user);
>>
>>         // Retrieve created user id
>>         String path = response.getLocation().getPath();
>>         String id = path.substring(path.lastIndexOf('/') + 1);
>>
>>         // Remember to close the response
>>         response.close();
>>
>>         // Set password
>>         CredentialRepresentation credentials = new
>> CredentialRepresentation();
>>         credentials.setType(CredentialRepresentation.PASSWORD);
>>         credentials.setValue("password");
>>
>>
>> keycloak.realm("realm").users().get(id).resetPassword(credentials);
>>
>>         // Add role
>>         RoleRepresentation role =
>> keycloak.realm("realm").roles().get("role").toRepresentation();
>>
>> keycloak.realm("realm").users().get(id).roles().realmLevel().add(Collections.singletonList(role));
>>
>> That's pretty rubbish right?
>>
>> In my opinion a lot of the usability issues is caused by directly
>> exposing interfaces/proxies from RestEasy Client and it would be much
>> better if we introduced a wrapper around it.
>>
>> So my questions are:
>>
>> 1) What do we do with regards to admin client? Do we just wrap what we
>> have, keep it or create a brand new one from scratch?
>> 2) Is it an issue that we require a specific RestEasy version to use the
>> admin client? This seems a heavy dependency to me, which could conflict
>> with other JAX-RS libraries. Using JAX-RS 2 Client would be an improvement
>> as it should in theory work with any JAX-RS 2 provider.
>> 3) What do we do with current fixes for admin client? Do we merge to
>> master and 1.9.x or just merge to master?
>>
>> At least from my POV the answers are:
>> 1) Create wrappers around interfaces/proxies from RestEasy client and not
>> expose JAX-RS directly through the API as that should be an implementation
>> detail
>> 2) Use JAX-RS 2 client
>> 3) Merge fixes to both master and 1.9.x (admin client is not supported in
>> product for now, so it's less risky)
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160405/81397430/attachment.html