[development] Getting both better internal and external APIs intoDrupal 7
nedjo at islandnet.com
Sun Dec 30 03:07:31 UTC 2007
> 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.
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
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",
More information about the development