After you have installed the Services module and created a service, you can test whether it is working by enabling a resource and retrieving that resource. During initial testing, it will make your life easier if you disable all authentication. You can enable the authentication later after you have confirmed that the service you have created is returning results as expected.

For the purpose of this test, we will assume that you have created a service named "test_service" with an endpoint of "test" and a REST server. We will also assume that you have not yet enabled any authentication. If you edit your service at /admin/structure/services/list/test_service you should therefore see something like this:

Using the node resource for testing is a good way to get started because creating nodes is easy in Drupal and because the Services module provides the full range of CRUD methods for nodes: create, retrieve, update, delete (and index).

1. Make sure anonymous users have permission to view nodes

This page is a description of the cover story and the necessary details. Specifications for each components are clear about what is defined and what is not defined. Furthermore, specifications indicate what areas are likely to change in the future. A specification is a difficult document to write, and it is more than just a paragraph or two about the component.

API Specifications

This API is build upon the RESTful service, full specifications can be found here: http://blizzard.github.com/api-wow-docs/. In its complete version, the Blizzard Community Platform API will make use of the entire service provided by Blizzard.

The base WoW component support EU, US, KR, CN and TW regions. The list of supported regions with miscellaneous information can be retrieved by the wow_api_info() function. The component is a sort of infrastructure for other components, declaring a wow_http_request() function that take care of service communication.

wow_http_request()

Test-infected development

Here is a very nice article written by Adobe on their Cairngorm 3 framework:

Test-infected developers never write their tests days after their code. Test-infected developers want to write tests, because that's the way they think about software development. They don't want to think otherwise. Test-infected developers never have excuses not to test. They are never too busy to test, their environments never take up too much time to create test data, and their customer never complain that testing is too expensive because it takes too much time.

If it is difficult to create an environment of test infected developers,

• analyze the design of the application for testable code, prevent repetitive and over-specified tests, keep tests small, easy and close to the way objects are used in production.
• don't attempt to test every single line of code in your application. Realize that functional tests have a role. Focus your unit tests to test behaviour and not structure and wiring.
• ensure libraries, frameworks, API projects, any other code that is shared by multiple developers achieve the highest coverage and quality of tests.

Default refresh mode

When you work with remote entities (such as Characters, Guild and Items), if you don't like the default modes, you can write your own method for refreshing an entity. Three methods for refreshing entities are supported out-of-the-box and a threshold can be set.

1. At loading time: each time you load a remote entity from the database, the lastFetched timestamp get checked, and the entity get refreshed from the battle.net API if needed (compared with threshold value). Because each time an entity needs an update, the loading hook make a remote API call, this mode is best suited for small guild website for instance where you need the last up-to-date information.
2. Via cron: each cron runs, all remote entities that needs a refresh will be queued in a separate thread using the Drupal cron queue API. This allows long running tasks such as massive character update to be run in parallel for instance. This mode is best suited for both small guild website or large community website as the remote API call is defined.

The World of Warcraft API is a set of a base component and products to integrate with drupal core. This set of modules enables communication with the RESTful APIs exposed through the World of Warcraft community site.

http://blizzard.github.com/api-wow-docs/

The installation process of this module is very easy, you just download the suitable version for your Drupal core version, and enable it (How to Install a module in Drupal 7).

The Blizzard Community Platform API 7.x requires the Entity Module. The 8.x version does not need this dependency as Entity Module is part of Drupal 8.x core.

After enabling Blizzard Community Platform API, go to your configuration pages (admin/config) and enter World of Warcraft > General Settings. Alternatively, you can click on the configure link on the modules page.

In the configuration pages, you can set your regional settings, the default locale, and your private API key. Note that the base module does not make use of the default regional settings but developers that build upon this library may require this settings so it is considered as good practise to check them.

WoW Data Services

Enabling the wow base module will grant you access to the WoW Data Services, sort of daemons that periodically fetch data resources for a given region and language. You can have more information on implementation in the developer documentation.