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