RESTPML - ObjectClass in URI

[Gary Cole <gary.cole@oracle.com>]

At least one member has questioned recently the presence (in the  
proposed RESTful binding for SPML) of object-class (class-id) in the  
URI for each object.  Karsten Huneycutt, for example, remarked that he  
found this odd.  (This emerged during discussion of the proposal for a  
Standard Schema (SIMPLEST).  In considering whether a single object  
could be exposed as both Person and Account, one implication was that  
in RESTPML there would be two URIs to this one object.)

I very much want to discuss this on the list.  We need open and  
balanced consideration of this question.  Because I have been acting  
as chair since the departure of Richard Sand, and because I have been  
the main contributor thus far to both RESTPML and SIMPLEST, there are  
fewer checks and balances to my opinion than would be ideal.

I must confess a potential bias.  It occurs to me that my experience  
with provisioning-connectors over the years may have influenced  
overmuch the proposal for RESTPML.  I've been closely involved over  
the course of many years with many forms of connectors to systems and  
applications and other identity-stores.  These include Waveset  
Lighthouse--AKA Sun Identity Manager (SIM) AKA Oracle Waveset-- 
Resource Adapters, followed by (both open-source and proprietary)  
Identity Connectors, followed by Oracle Identity Manager (OIM)  
Connectors, followed by so-called converged OIM Connectors that use  
Identity Connectors as a component technology.  I mention this both in  
the interest of full disclosure  and to qualify that potential bias.

In my experience with provisioning-connectors, the target system or  
application almost always segments objects by type--i.e., by class of  
object:
- The names of objects are often unique only within each particular  
type of object.
- Search and list functions are often specific to each particular type  
of object (and may be inconsistent across types).
- Some types of objects may be represented as data-objects where other  
types are accessible only through APIs.
- Some attributes of each object may be represented in a data-objects  
where other attributes are available only through APIs.
- Connectors often construct a unique ID from by combining object- 
class and name--especially when no GUID is available natively.

Under these circumstances, the approach of always accessing object- 
instances within (the scope of a containing) object-class:
- Makes it easier for a provider (who knows without asking which type  
of object is relevant--and thus which backend implementation to use).
- Makes it easier for a client (who often cares about only one type of  
object--e.g. ACCOUNT):
  -- Client need not specify object-class to each request.
  -- Client need not remember which attributes are queryable for each  
type of object.

Technically, nothing in this approach prevents a provider from:
- Exposing everything under a single object-class--e.g., OBJECT.
- Exposing the particular object within multiple object-classes:
  -- e.g., the same object might be an instance of Object, Person,  
OrgPerson and InetOrgPerson.
  -- Classes that are more abstract expose fewer attributes that are  
queryable than classes that are more concrete.
  -- The main weirdness is that in RESTPML today multiple URIs could  
refer the same object.

However, this approach seems a bit clunky to someone who is accustomed  
to accessing objects via LDAP:
- LDAP allows object-classes to extend (i.e., inherit from or  
subclass) other object-classes.
- An object may implement several different object-classes.
- Objects are organized by containment (e.g. the Directory Information  
Tree or DIT) rather than partitioned by object-class.

For that matter, the current proposal for RESTPML goes beyond what is  
specified by SPMLv2:
- The base specification of SPMLv2 does not require object-class (only  
the DSML profile does).
- The spec for the DSML profile describes the "objectClass" attribute  
explicitly as multi-valued.
- PSOID is specified as unique within target (and does not mention  
object-class explicitly).

The question thus becomes: What would change in RESTPML if object- 
class were not part of the URI to each Object?

Members, please consider this question in general, as well as  
considering the interests of your respective member-organizations.   
What makes the most sense for the standard?  Would either approach be  
acceptable?  Is one approach clearly better?

Off the top of my head, I suspect that either approach could work.  If  
object-class were no longer part of each object-URI:
- RESTPML would become much more like LDAP.
- A client that is interested in a single type of object may need to  
specify object-class in each request to create, search and list objects.
- A provider that supports multiple types of object may need to  
require an object-class argument for certain operations.
- A provider may need to switch internally (e.g., validate attributes  
and point to a particular set of backend APIs) for each object-class.
- The ID of an object may need to combine object-class and name (if no  
GUID is available) and if the backend segments objects by type.

Gary