[development] Getting both better internal and external APIs intoDrupal 7

[Nedjo Rogers]

>  better APIs would be best solved by converting everything
> (users, comments, terms) to nodes.

Let's clarify the problem and look at the various options folks have taken 
or mapped out.

Currently we have various different object types (nodes, users, terms, 
etc.), each with their own distinct APIs. Of these, nodes are most fully 
developed and have various properties and features (an access system, 
revisions, etc.) not available to other objects.

Problems:
a. Difficulties, duplication, barriers, etc. introduced by having distinct 
APIs and custom methods for each object type.
b. Non-nodes are second-class objects, lacking much of the powerful node 
APIs.

Potential solutions:

1. Parallel implementations.

Create parallel implementations for other object types, giving them the 
functionality that nodes have. E.g., a taxonomy access system similar to the 
existing node_access one.

2. A node type for every object type, a node for every object.

Create special node types to extend other objects, e.g., a 'user' (or user 
profile) node type, enabling non-node objects to receive node properties. 
The various node profile approaches fall into this category.

3. Everything's a node.

Make everything a node, with specific object types (e.g., users) extending 
the node object.

4. Generalize node APIs.

Take a lot of what currently is node-specific and generalize it so that it 
can be applied to any object type. E.g., rather than the node access system, 
an access system for any object type. A potential example to work from here 
is the search indexing API, which, while implemented only for nodes in core, 
nonetheless tracks a search 'type' that could be any object type.

5. New base object type.

In addition to 4, introduce a new minimal base object type that all object 
types (nodes included) extend.

Of these options:

1 and 2 have often been tried and, I think, most developers would agree they 
are at best only stop-gap solutions. 1 doesn't address problem a 
(difficulties, duplication, etc.). 2 introduces various problems of 
synchronizing, automating, etc. 3, everything's a node, is understandably 
attractive but has limitations that have been pointed out: nodes come with a 
lot that may or may not be applicable to other object types.

Which in my view leaves us with 4 and 5 plus any other approaches creative 
minds may add to the list. Henrique Recidive and I worked with approaches 4 
and 5 in sketching out ideas for D7 data APIs in "Data APIs for Drupal 7 and 
web services support", http://groups.drupal.org/node/6767 and "Active 
Records, a possible approach for consistent Data APIs", 
http://groups.drupal.org/node/6772.