This is a brief introduction to how the rest server works.

Controllers

Tabulation of the controller mapping for the REST server. Requests gets mapped to different controllers based on the HTTP method used and the number of parts in the path.

Count refers to the number of path parts that come after the path to identify the resource type. The request for `/services/rest/node/123` would have the count of 1, as `/services/rest/node` identifies the resource type, followed by the nid identifying the desired resource.

C,R,U,D,I = Create, Read, Update, Delete (CRUD) and Index requests
A = Action
T = Targeted action
X = Relationship request

    COUNT |0|1|2|3|4|N|
    -------------------
    GET   |I|R|X|X|X|X|
    -------------------
    POST  |C|A|T|T|T|T|
    -------------------
    PUT   | |U| | | | |
    -------------------
    DELETE| |D| | | | |
    -------------------

CRUD

The basis of the REST server. In the below:

• [endpoint_path] refers to the Path to the endpoint you defined when setting up the endpoint.
• [resource] is the name of the resource, like node or taxonomy_term.
• [resource_id] is the id of the resource you're acting on.

Create: POST /[endpoint_path]/[resource] + body data
Retrieve: GET /[endpoint_path]/[resource]/[resource_id]
Update: PUT /[endpoint_path]/[resource]/[resource_id] + body data
Delete: DELETE /[endpoint_path]/[resource]/[resource_id]

And last but least, the little bastard sibling to Retrieve that didn't get its place in the acronym:

Index: GET /[endpoint_path]/[resource]

For example, to fetch a taxonomy term, you could use:

GET: /my_endpoint/taxonomy_term/5

Where 5 is the tid of the term to fetch.

If you wanted that term's data in json format, you'd use:

GET: /my_endpoint/taxonomy_term/5.json

In the REST server the index often doubles as a search function. The comment resource allows queries like the following for checking for new comments on a node (where 123456 is the timestamp for the last check and 123600 is now):

New comments: GET /services/comment?parameters[nid]=123&parameters[timestamp]=123456:

Actions

Actions are performed directly on the resource type, not a individual resource. The following example is hypothetical (but plausible). Say that you want to expose a API for the [apachesolr][apachesolr] module. One of the things that could be exposed is the functionality to reindex the whole site.

Reindex: POST /services/rest/apachesolr/reindex

Targeted actions

Targeted actions acts on a individual resource. A good, but again - hypothetical, example would be the publishing and unpublishing of nodes.

Publish: POST /my_endpoint/node/123/publish

Relationships

Relationship requests are convenience methods (sugar) to get something that's related to an individual resource. A real example would be the relationship that the [comment_resource][comment_resource] module adds to the node resource:

Get comments: GET /my_endpoint/node/123/comments

This more or less duplicates the functionality of the comment index:

Get comments: GET /my_endpoint/comments?nid=123

Notes - Please rewrite me

This section is an incomplete list of helpful docs since we're moving away from using comments on Documentation pages.

Camil Sumodhee notes that if you are implementing a REST Server using XML where controller arguments / source are 'data', then you need to implement your own parser. You can define your own parser in hook_services_resources() as follows:

'rest request parsers' => array('text/xml' => '_mymodule_xml_parser'),

You want to make sure you return an array so it fits into the Services model $sources['data'][$key] where $key is the key of your resource argument.