You are viewing a plain text version of this content. The canonical link for it is here.
Posted to scimple@directory.apache.org by Kyle Thorpe <kt...@proofpoint.com.INVALID> on 2024/07/16 15:31:19 UTC
Updating Resources That Do Not Exist
Hello all,
I’m reviewing some logic in our SCIMple implementation and am curious what is expected for the `update` and `patch` implementations when the client attempts to update a resource that does not exist (or is marked as `deleted`).
If I recall correctly, SCIMple used to do a `get(id)` behind the scenes to find the user or not, but this was removed when `update` and `patch` were split out. If SCIMple does not handle this behind the scenes, what should be returned from the update and patch methods to let the client know that the resource does not exist? Currently, it expects the resource, such as a `ScimUser`.
Thanks!
Re: Updating Resources That Do Not Exist
Posted by Brian Demers <br...@gmail.com>.
I put together a PR with a new `ResourceNotFoundException` based on this
thread
https://github.com/apache/directory-scimple/pull/632
There are a bunch of changes in there, but 99% of it is just updating the
tests to check for this condition. Please take a look!
On Tue, Jul 16, 2024 at 2:59 PM Brian Demers <bd...@apache.org> wrote:
> Great question!
>
> This is probably one of those things that could use its own section in the
> README (or other docs), or maybe just called out in the Javadoc...
> And probably in the example projects too, as it doesn't look like that is
> covered.
> And while I'm thinking about it, this could be a useful add to the
> compliance tests too
>
> Anyway...
> For this case, throw a `ResourceException` (or one of its subtypes).
>
> More detail:
> A little bit of the http layer (SCIM protocol layer) bleeds into this
> exception, as one of its constructor args is a `statusCode`, which maps
> directly to the HTTP status that will be returned.
>
> There is probably a more elegant way of separating the layers. 🤔 Maybe
> create specific exceptions (e.g. ResourceNotFound), and them map them via
> a jakarta.ws.rs.ext.ExceptionMapper, but there would still probably be edge
> cases missed 🤷
>
> Or maybe in the short term, we create a few more exceptions that look like
> the `ConflictResourceException
> <https://github.com/apache/directory-scimple/blob/a68647b08cc42df75ef12ebf48fe773f55014e48/scim-spec/scim-spec-schema/src/main/java/org/apache/directory/scim/spec/exception/ConflictResourceException.java#L25-L29>`,
> which better _hides_ the protocol layer detail 🤔
>
>
> Hopefully this helped and as always, if you have ideas or thoughts on
> improvements around this please let us know !
>
>
>
>
> On Tue, Jul 16, 2024 at 11:31 AM Kyle Thorpe
> <kt...@proofpoint.com.invalid> wrote:
>
>> Hello all,
>>
>> I’m reviewing some logic in our SCIMple implementation and am curious
>> what is expected for the `update` and `patch` implementations when the
>> client attempts to update a resource that does not exist (or is marked as
>> `deleted`).
>>
>> If I recall correctly, SCIMple used to do a `get(id)` behind the scenes
>> to find the user or not, but this was removed when `update` and `patch`
>> were split out. If SCIMple does not handle this behind the scenes, what
>> should be returned from the update and patch methods to let the client know
>> that the resource does not exist? Currently, it expects the resource, such
>> as a `ScimUser`.
>>
>> Thanks!
>>
>
Re: Updating Resources That Do Not Exist
Posted by Brian Demers <bd...@apache.org>.
Great question!
This is probably one of those things that could use its own section in the
README (or other docs), or maybe just called out in the Javadoc...
And probably in the example projects too, as it doesn't look like that is
covered.
And while I'm thinking about it, this could be a useful add to the
compliance tests too
Anyway...
For this case, throw a `ResourceException` (or one of its subtypes).
More detail:
A little bit of the http layer (SCIM protocol layer) bleeds into this
exception, as one of its constructor args is a `statusCode`, which maps
directly to the HTTP status that will be returned.
There is probably a more elegant way of separating the layers. 🤔 Maybe
create specific exceptions (e.g. ResourceNotFound), and them map them via
a jakarta.ws.rs.ext.ExceptionMapper, but there would still probably be edge
cases missed 🤷
Or maybe in the short term, we create a few more exceptions that look like
the `ConflictResourceException
<https://github.com/apache/directory-scimple/blob/a68647b08cc42df75ef12ebf48fe773f55014e48/scim-spec/scim-spec-schema/src/main/java/org/apache/directory/scim/spec/exception/ConflictResourceException.java#L25-L29>`,
which better _hides_ the protocol layer detail 🤔
Hopefully this helped and as always, if you have ideas or thoughts on
improvements around this please let us know !
On Tue, Jul 16, 2024 at 11:31 AM Kyle Thorpe <kt...@proofpoint.com.invalid>
wrote:
> Hello all,
>
> I’m reviewing some logic in our SCIMple implementation and am curious what
> is expected for the `update` and `patch` implementations when the client
> attempts to update a resource that does not exist (or is marked as
> `deleted`).
>
> If I recall correctly, SCIMple used to do a `get(id)` behind the scenes to
> find the user or not, but this was removed when `update` and `patch` were
> split out. If SCIMple does not handle this behind the scenes, what should
> be returned from the update and patch methods to let the client know that
> the resource does not exist? Currently, it expects the resource, such as a
> `ScimUser`.
>
> Thanks!
>