Searching for

http://drupal.org/search/node?keys=api+type:project_project&from=0

results in a quite great listing of projects that are APIs or helpers. Since we want to let module developers rely on existing functionality instead of implementing the same from scratch, it would be a very useful resource.

Moreover, this hopefully could lead to more generic API modules for Drupal and a sensitisation for reusability of certain modules/functionality. It's frustrating to have a research result like that for addressbooks.

Comments

sun’s picture

Title: Add 'APIs' module category » Add 'API' module category

IMHO, this becomes more and more important. Does noone agree?

apaderno’s picture

Status: Active » Closed (won't fix)

The use of a free tagging vocabulary will solve this.

sun’s picture

FWIW, I don't think so. We still need hard-coded categories (next to free-tagging), and the suggestion was to add "API" as a new static category. Using free-tagging, you can further tag modules in the API category into further sub-categories.

apaderno’s picture

Status: Closed (won't fix) » Active

That is a good point.
I am actually pro this feature, even if I am worried that most people will select it for modules that don't expose a public API (except the Drupal hooks they implement). I agree that there are many modules that need to be installed only if another module requires them; those are perfect candidates for the category you are suggesting.

apaderno’s picture

Doesn't anybody else have an opinion on this?

Damien Tournoud’s picture

I'm -1 on this. "Api" is to broad a category to be remotely useful.

apaderno’s picture

Title: Add 'API' module category » Add a category for the modules that expose an API, but not a user interface

Is there another term that could be used, and which clearly identify all those modules that don't expose a user interface, and that are only a repository of functions for other modules?

I understand that API is too generic, and all modules exposes an API through the hooks Drupal core code uses. Still, I think that it could be useful to have a category for that kind of modules; in that way, normal users would know that those modules are not of interest of them (if another module doesn't instruct them to install one of those modules). Differently, developer users could be interested in looking at those modules, especially if they need to implement a functionality in their module, and need to know if there is a module that could help them.

Maybe it would be a few used category, but there are some modules that report a sentence like "don't install this module if another module doesn't instruct you to do so".

apaderno’s picture

Status: Active » Closed (won't fix)

I was getting that no comments would mean nobody would care if this category would have been added.
As I was said I was wrong, I must then take nobody is pro adding this category.

Stalski’s picture

Status: Closed (won't fix) » Active

I posted a post with an open question. Sun directed me to this page as the question indeed suits this topic. (see Moderated API contributions in drupal)

The post was basically about the problem of having several API's available leaving a difficult choice for webmasters and drupal contrib developers that have a dependency on such an API.

We want developers to have free choice to develop custom, faster, better, etc ... but we want to keep drupal contributions a clean repository. If we do go on like this, it's obvious it will lead to even more scattered modules.

One of my suggestions is very much related to this, as it would use category or labels as well.

Suggestion 1

As we mainly want to have an easy reliable choice based on usage stats and reviews when chosing modules, we could label contributions as API, freely the choice of the maintainer. By selecting "This is an API module", the developer commits himself to a different kind of contribution, where the maintenance differs in severity and number of developers active.
This way ready-to-go modules and api’s that don’t want to be labeled this way can still go ahead. The choice should indeed be left to the maintainer.
What does the label API do then? Time will tell. Could be a "recommendation"? It sure wouldn’t be left without maintainer that easily. Is this a sollution for dependencies in other contributes, even wanting to set a "default API"?
The sollution could satisfy pros and cons. What i hope would happen is that some maintainers will end up labeling their module as the API to use and others creating new api projects in a collaboration of developers to merge and filter the best of several api’s.

Suggestion 2

My biggest worry is that i often need a simple way of collecting data that can be done by various of api's. Lets take the user relationships for instance. Heartbeat or some chat module needs to call "get_friends($uid)", and it's hard and even ugly to make a dependency on one the the API's as you leave the enduser with a big restriction. Or you need to detect a "friendlist" module to let a generic function return all friends.

We could create an adaptive APIPluginmanager where you can register api's to. This would be part of a small layer between drupal and contributions.
PseudoCode:
APIPluginManager::getInstance()->registerAPI($api, UserRelationPlugin);
$api is the name of the type of api. E.g. : user relationships, flag_friend, friendslist, ... . The UserRelationPlugin-part is automatically detected/registered so the drupal site allows the registration of a user relationship api in the first place.
In the end, it would let us do something like
PseudoCode:
APIPluginManager::getInstance()->invoke('get_friends'); without having to worry about the internals of the concrete implementations.

Dave Reid’s picture

If we add a category called API, where does it stop? Anyone can select the terms for their own project. It's not moderated. Module author Sam who's little module provides two small hooks thinks he should list it, while module author Sally, who's project is itself an API meant for other modules (e.g. Voting API) also wants to list hers.

I still think the best way for this is to title your project with '[thingy] API' as the title. It's a clear indication that the module itself is the API.

Stalski’s picture

You know what, i will try to create a POC with ctools, as this module is the way to go these days and it can indeed make all apis with the same purpose work the same way.

apaderno’s picture

I agree with Dave that a term like API is too generic; as all modules implements hooks, all modules could be considered under that category, which would create more confusion.

apaderno’s picture

Status: Active » Closed (won't fix)

Damien Tournoud, and David Reid have given a −1 to this feature; considering that the argumentation given from Dave Reid is valid, I am marking this feature report as won't fix.