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?

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.

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.

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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev