Services is a module that makes it easy to provide web services using Drupal. What services doesn’t do is to allow the definition of separate API:s. This is something we need to fix if we want to turn services into a real web-service framework.

Consider the following: Today all installed services are always available on all installed servers and they all have to use the same authentication method.

This is what makes services practically useless as a building block for other modules, and what makes is nigh on impossible for API:s to coexist in one Drupal install. This worked fine when services only was used for integration with a single Flash/Js/external application; when it was installed by the developer/admin to solve one specific task.

Now we’re nearing a point where both blog api and pingback implementors are looking to leverage services for their modules. This is great, as our goal must be that everybody implementing any kind of web service should look to services (core inclusion on the far horizon). Unfortunately it’s not possible with the way services is constructed today.

The proposed solution

What I propose, and have gotten quite far with implementing, is to introduce the concept of separate endpoints. Endpoints allows modules and administrators to define separate API:s. By this I mean that each endpoint will provide the following information:

• which services should be exposed
• with what server and on which path they should be exposed
• how should the clients authenticate themselves

The endpoints can be customized completely independently of each other. Endpoints can also be created directly through the administrative interface. The plan is to use ctools for the endpoint information, which will give us exportables for API:s, correct handling of loading of definitions from code and database, overrides et.c.

I’m really exited about the possibilities that this provides, and how it ties in with features. I see it as absolutely essential for services continued development, and not as a good-to-have extra. That is not to say that it needs to be implemented exactly as I’ve done it. But we need the core functionality.

The current state of 3.x

I’ll illustrate with some screenshots from a site running the endpoints-branch from github:

This is the new (when say new throughout the post I mean ”my proposed new”) first-page for services admin. It lists the services endpoints in the installation and some brief info about the path, server and authentication module that’s used, and it lists the active services for the endpoint. The services that are listed may be fully or partially enabled.

This is a shot of the edit endpoint page. Here you can choose the path for the endpoint and which server and authentication module that should be used in the endpoint. Here you can see that the oauth module has gotten a new configuration which is OAuth context, described pretty well in the form: ”The OAuth contexts provides a scope for consumers and authorizations and have their own authorization levels. Different services endpoints may share OAuth contexts and thereby allow the use of consumers and tokens across the services endpoint boundraries.”

This page allows you to select which services and controllers will be exposed at the endpoint, and allows the authentication module to supply options for each controller.

What I like the most is the ability to define a services endpoints in code. Here we have the conglomerate module that I’m currently working on that defines it’s own endpoint. This way modules can expose their own API:s and own authentication settings without disrupting each other.

The same goes for oauth_common, where modules now can define their own oauth contexts. Both these are perfect candidates for chaos tools integration, and ties in perfectly with the features-way of thinking.

Endpoint branches:

• Services
• REST Server
• OAuth Common
• Services OAuth