possible bug in getControllerArguments() in RESTServer.inc doing a PUT

(I've elevated the status of this issue to 'critical' because according to http://drupal.org/node/45111, this issue renders the REST server system unusable - Create and Update operations are impossible with how the code is written and how the example shows one to use the Create and Update operations.)

In an effort to get this working, I've modified the source of getControllerArguments() such that both POST & PUT are being handled correctly. Here's my reasoning, using Hugo's noteresource & noteresourcejs modules as my example to illustrate how this bug occurs:

In Hugo's notes.js example, the data for a Create-POST is constructed like this:

 var data;
data = {
        subject: $(subject).val(),
        note: $(text).val()
      };
noteapi.create(data, note_saved);

while the Create controller inside noteresource.module is defined like this:

'create' => array(
       'help' => 'Creates a note',
       'file' => array('file' => 'inc', 'module' => 'noteresource'),
       'callback' => '_noteresource_create',
       'access callback' => 'user_access',
       'access arguments' => array('note resource create'),
       'access arguments append' => FALSE,
       'args' => array(
         array(
           'name' => 'data',
           'type' => 'struct',
           'description' => 'The note object',
           'source' => 'data',
           'optional' => FALSE,
         ),
       ),
     ),

Which means that inside getControllerArguments(), after the "Get argument sources" portion, the $sources array will look like this:

array( path => array(),
          param => array( q => {the endpoint path} ),
          data => array( subject => 'a subject', note => 'a note' )
        )

Then this code fragment a bit lower inside the "Map source data to arguments" portion is how the Create-POST's data is assigned to the arguments array:

              if(isset($sources[$info['source']][$info['name']])) {
                $arguments[$i] = $sources[$info['source']][$info['name']];
              }
which is the same as:
              if(isset($sources['data']['data'])) {
                $arguments[$i] = $sources['data']['data'];
              }

And as you can see, that isset() contents does not exist, it is trying to access inside the data rather than assign the data itself to the $arguments array.

Now I modified that assignment logic like this:

             if(isset($sources[$info['source']][$info['name']])) {
                $arguments[$i] = $sources[$info['source']][$info['name']];
                _devReport('Original-good!');   // appends this message to a text file 'cause I don't have step debugging
              } 
              else { 
                if(isset($sources[$info['source']])) {
                    $arguments[$i] = $sources[$info['source']];
                    _devReport('New-Good!');   // appends this message to a text file 'cause I don't have step debugging
                }
              }

This modification makes all the data for a Create-POST arrive at the controller callback and it also makes Update-PUTs operate correctly for the exact same reasons.

It may also be worth noting, that as I test all the CRUD verbs, the 'Original-good' message never gets echoed. I've left in it place because I don't know if that original logic is necessary for Actions, Targeted Actions or Relationships.

Sorry, I have not rolled this modification into a patch. I don't use CVS or git, and according to the 'Creating a patch' documentation here at Drupal.org, making a patch with diff is unreliable.

Yes it does. That is the bug that prevents Create-POSTs and Update-PUTs from working correctly with how Hugo's example demonstrates the packaging of the data for the POST and PUT.

Perhaps Hugo's data packaging example is incorrect, and rather than:

var data;
data = {
        subject: $(subject).val(),
        note: $(text).val()
      };
noteapi.create(data, note_saved);

The data should be packaged:

var data;
data = {
        data: { subject: $(subject).val(),
                   note: $(text).val()
                }
      };
noteapi.create(data, note_saved);

That would make the original logic for a Create-POST work correctly (but break Hugo's example) and a similar data-object-inside-the-outter-most-data-object packaging for Update-PUT would also work with the original logic.

I'm happy to write a test case, but I'm unfamiliar how. I've not used simpletest before; that is what you're referring to, correct?

I have been doing this debugging in an api_shell and api_shell_test modules, where the Service implementation lives in api_shell, and the javacript logic that I'm using to do my debugging tests lives in api_shell_test.

It is my intention to contribute the working api_shell to the Services team as a working example that demonstrates CRUD as well as Actions, Targeted Actions and Relationships.

Would making the api_shell & api_shell_test modules more easy to use, as in not requiring FireBug to run the tests, be good enough?

I'll take a look at the simpletest documentation to see if it's a no-brainer...

Sorry, yes, bumping it back to critical was an accident.

Looking at tests/functional/ServicesResourceNodeTests.test, I see that it is object orientated PHP, which I've not done much development in. Now, C++ OOP I'm great at, but I hesitate because my weak OOP-PHP may implement a buggy test.

However, reading both the POST and PUT tests in tests/functional/ServicesResourceNodeTests.test, I can see that both the POST and PUT data is packaged as I suggest in my post #3, above.

So, I think that is the solution. Give me a few beats (since it is end of day here) and I will bring my api_shell & api_shell_tests up to date with this solution and post them here, or somewhere else you direct me to place them.

BTW, thank you so much for your work here. I've privately told Hugo that I believe Services is the most significant Drupal module, period. I'm not really a 'web guy', and Services enables me to create critical systems for my business.

As noted in post #7 above, the original Services code is correct, but the example for calling both POST & PUT operations from java script at http://drupal.org/node/783460 is incorrect.

Attached is a zip file containing two modules:
api_shell.module an example showing how to setup a RESTful API, with the CRUD operators working except for index parameters
api_shell_test.module a java script testing framework for verifying that the API setup in api_shell.module works

Camil,

Thank you for your post! I was just sitting down to write code that would have required exactly what you just posted.

Question: where does your parseXMLtoArray() routine come from? As I Google around, I'm seeing various resources for conversion to and from XML/PHP-Arrays. Yours looks very compact and easy to use, verses many I'm finding on the 'net with apparent complexity that seems unnecessary to me...

My Googling has also revealed various Drupal.org forum posts recommending the QueryPath.module for working with XML. I'm looking into that too... (Wow, just finished reading/watching info about QueryPath. If you're unfamiliar, it's worth your time.)