On 18 December 2017 at 13:57, John D. Ament <john.d.ament(a)gmail.com> wrote:
On Mon, Dec 18, 2017 at 12:51 AM Stian Thorgersen <sthorger(a)redhat.com>
> The unique ID is being returned as part of the Location header. This is a
> standard way of doing things. I don't like your proposal of returning an ID
> header as that's something custom that at least I've not seen done
> I appreciate the fact that the Location header has to be parsed, but
> adding a new custom header isn't the solution IMO.
Agreed. I wanted to better understand where we're struggling. Looking at
the code, would it make sense for Keycloak's Admin client to provide a
utility that can parse the header to retrieve the ID portion of the URL, so
that consumers don't need to parse it themselves?
That would probably be the simplest option. We already to this in the
Could you extract the getCreatedId method to a new Util class within
> We would not consider this for 3.x so it wouldn't be merged until the new
> year at the earliest. We'd also need an agreed pattern that should be
> discussed on the mailing list prior to sending a PR. It would have to be
> complete (all endpoints updated) and come with tests.
> On 14 December 2017 at 15:38, John D. Ament <john.d.ament(a)gmail.com>
>> I'm planning to start to submit some PRs for
. If I start to get them
>> you in the next few days, what would release would they target. Some of
>> the items I'm looking to immediately leverage are:
>> - Create User
>> - Create Group
>> - Create IDP
>> These are the important ones since fetching the data a second go around
>> requires that unique ID in the URL.
>> keycloak-dev mailing list