bdemers commented on PR #411:
URL:
https://github.com/apache/directory-scimple/pull/411#issuecomment-1812909404
> However, can we get some better comments/documentation about what,
specifically, about the incoming PUT or PATCH requests determines whether the
`update()` or `patch()` flows are used? In general, I tend to get lost in
SCIMple when looking for the endpoint/controller-level logic. In this PR as
well, I've missed (at least on a first pass) where the main logic is for
SCIMple to decide whether to use `update()` or `patch()` based on the incoming
request that it's handling.
Absolutely!
IMHO, the high level goal is that folks _shouldn't_ need to know any of the
detail of the REST layer, and only need to implement the `Repository` API.
This will need to be expanded on in the javadoc and other docs, but here are
some key points:
- There are two ways to modify an existing resource:
- a replacement of a resource, `PUT` request, which calls
`repository.update(...)`
- a partial update of a resource, `PATCH` request which calls
`repository.patch(...)`
Maybe it would be helpful to have a table mapping the SCIM protocol requests
back to the repository method:
(not completely accurate, mostly thinking out loud for how this might look)
| REST Endpoint | REST method | Repository method |
|----------------|---------------|--------------------|
| /Users | `GET` | `repository.query()` |
| /Users/{id} ` | `PUT` | `repository.update()` |
| /Users/{id} ` | `PATCH` | `repository.patch()` |
...
As an aside, while talking about the javadocs, I'm not sure the
Swagger/OpenAPI annotations in the REST layer add value to the user. (As the
OpenAPI spec for SCIM could be defined by the body managing the RFC, or other
project, that OpenAPI spec doesn't change unless the RFC is updated)
Anyway, I've wondered if removing it would make it easier to read/understand
the code. (Or if I'm just over thinking it and that's not a problem at all)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
