search

hiro117 / scim

Automatically exported from code.google.com/p/scim
0 stars 0 forks source link

Adding clarification to the specs on the blurred lines between SCIM apis AND corresponding extended REST apis. #100

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
As per the spec here:

The SCIM protocol specifies well known endpoints and HTTP methods for
   managing Resources defined in the core schema; i.e., User and Group
   Resources correspond to /Users and /Groups respectively.  Service
   Providers that support extended Resources SHOULD define Resource
   endpoints using the established convention; pluralize the Resource
   name defined in the extended schema by appending an 's'.  Given there
   are cases where Resource pluralization is ambiguous; e.g., a Resource
   named 'person' is legitimately 'persons' and 'people' Consumers
   SHOULD discover Resource endpoints via the Resource Type attribute
   'endpoint'.

I see that there is not much information on the extended subresources of the 
already defined well known endpoints. Here's an example.

Suppose an application has a User who HAS assigned Projects which inturn HAS 
assigned Tasks per project. In this case, the REST urls would look something 
like:

scim/v1/Users/{userId}/Projects/{projectId}/tasks.

My question is: does this still comply SCIM specs? Or resource handling like 
these should be on a separate REST platform because it doesn't have anything to 
do directly with Identity Management (although one might argue that these could 
be entitlements assigned to the User. But most of the times, these MIGHT NOT BE 
entitlements. Just some entities assigned to the user who inturn have entities 
of their own)

Another question here would be, if I am someone trying to write a generic 
SCIM-REST client based off of the specs, how would I take into consideration 
and handle the above resources because from what it seems, each scim service 
provider could have their own Object that a User gets in their application (or 
gets assigned to), for eg: Projects in the above case.

I guess it's more of a design question as to where a service provider should 
draw the line and encapsulate their apis as SCIM apis or dedicated REST apis. 
Whatever the specs define, it should be clear, especially when it's underlying 
implementation is indeed REST and service providers shouldn't get carried away 
with them "complying" with SCIM just because the "extended resources" are 
loosely defined in the specs.

Original issue reported on code.google.com by shiv...@totvslabs.com on 11 Dec 2013 at 4:59