A unique set of tools used for Services 3.x.

Currently services_tools houses two modules.

  • Historical
  • Definition

You can see them below.


An API for providing historical versions of a Services API. Any quality services implementation should be versioned to ensure incompatibility issues do not arise. Even a simple API used internally between two machines can benefit from versioning since it will allow the machines to be updated independent of one another. For full fledged public APIs versioning is also essential to ensure the stability of the service.

Instead of always pointing clients to the current API, use a version number even if there is only one. For example, api/foo becomes api/1.0/foo. This ensure that when you make changes and create api/1.1/foo that clients using api/1.0/foo continue to work and can upgrade at their leisure.

The API is quite flexible and provides a number of ways the historical API may be implemented. For details see services_historical.api.php and the original issue which describes the thought process.

Too see an example that walks through committing changes to a service and how the appropriate historical changes to make see https://github.com/boombatower/services_tools_example.


-Supplys interface for determining what methods require what parameters without having to look at the code.
-Gives a resource that allows the API to expose whats open and enabled.

Project Information