Testing resources

For the purposes of these tests, we will be using the user resource but these principles apply to any of the other resources as well.

The first thing you'll need to do to test your resource is figure out what path it lives under. This is put together from several pieces of information you entered into the Services admin screens. The formula is

http://<your_domain>/<your_endpoint_path>/<your_resource_path>/

Your endpoint path is defined in your endpoint's settings under 'Path to endpoint'.

Endpoint settings

To get your resource path, edit your endpoint, and click 'Resources'. Each resource you have enabled will be listed. Open 'user resource' and see if anything is entered for 'Alias'. If nothing is entered, then the name of the resource will be used. Otherwise, whatever is entered will be used.

User Resource Alias

So for this example, the path is

http://mydomain.com/test_endpoint/users

If you visit this URL in your browser, you should receive a white screen instead of a Page Not Found error. If you get a Page Not Found error, you definitely have something wrong.

Note that for the purposes of basic testing, it will make your life easier if you disable all authentication. You will still want to test this later, but for initial tests it is best to remove as many variables as possible.

Having determined the path to your resource, you will test in different ways depending on what server you are using. Please refer to the appropriate section below.

Bash script example for custom services action with session authentication

Here is Bash script example how to work with custom services action that requires session authentication.

Calling a REST Server using JSON with PHP

Here is a small module to access a REST server using PHP. The module assumes that you already have services installed with a REST server

Calling a REST server with Command Line cURL (login, create comment, logout)

Testing with command line curl can be useful since its easy to save your commands on a .txt file for future reference. The cURL webpage has

Communicating with a remote API, implemented as a Services 3.0 REST Resource

Do user login with curl and the services 3.x module in Drupal 7

Assume that I created an rest server endpoint:

Example REST server for node.create with session authentication (JSON & PHP cURL)

Endpoint requirements :

Example XMLRPC POST for node.create

Example POST (D6)

Example XMLRPC POST for user.login

Example POST

Example XMLRPC POST for user.register

Example POST

Making authenticated requests to REST Server

You can make authenticated requests to REST Server using standard Drupal session-based security with no effort on your part. This is managed

Services 3 - POST node.create with custom fields

Using the module Services to create a node with required custom fields may be challenging. Most of the problems fall on formatting the data

Services Sandbox. Testing resources on a test server.

Testing OAuth

After the installation of the OAuth module and the modules that OAuth depends on is finished, go to /admin/settings/oauth/list.

Testing a three legged OAuth using Services 7.x-3.x XMLRPC

After a couple of days bashing my head against my desk, I have finally got a C client to talk to Drupal 7.x using Services 3.x (XMLRPC) and

Testing a three-legged and two-legged OAuth REST, using Services 7.x-3.2 and Oauth 7.x-3.0, with PHP Client

Here I will post all my system settings and configurations to test it out.

Testing a two legged OAuth

This page describes how to use a two legged OAuth with Services 3.x and OAuth 7.x.

Testing with REST Server

To get the most out of this page, you should first take a look at Working with REST Server to get more of a conceptual overview on how the

Guide maintainers

gdd's picture