Services (rest_server) should have a requestParse for the appication/xml mime type [patch]

I got around to making a working test using PUT and XML. So the patch does fully work.

kylebrowning, sorry. It sounds like you were expecting that my test was a PHP unit test. The test I wrote to prove the patch does work is not a unit test but rather a functional test from a client (using curl as a client and bash as the language).

Here is the test that I was using. It basically uses curl to:
- authenticate
- store cookies
- fetch the node via an http GET and expecting XML from the server
- modify the XML retrieved (change the title)
- change the node that exists by supplying the modified XML via an http PUT command

Please let me know if this helps.

Wow! Thanks guys, I disappear for a bit and this thing continues to make progress. In response to cotto, the only reason for round tripping through JSON is that the JSON to PHP array conversion is/was a known supported conversion (it is what was already being used in the json content-type handler). I looked for a direct XML to PHP array method, but could not find such a thing. I figured it would more bug free to convert XML to JSON via a known good method, then JSON to PHP array via a known good method than to roll something myself.

aka. I am a PHP/Drupal n00b :-)

Here is one thing that have noticed when enabling XML support (it does not really make a difference which patch I try if I recall correctly (currently I am using the patch proovided in comment #11)).

Certain data structures within Drupal do not get serialized or unserialized correctly (I am not sure which one). Please bear with me as I try to coherently express the issue.

Lets say I do a GET on /node/123 with the "Accept: application/json" header set, and in the response I notice the following:

    "field_foo_txt": {
        "und": [
            {
                "safe_value": "<p>Test foo</p>\n",
                "value": "Test foo",
                "format": "markdown"
            }
        ]
    },

In a PUT with "Content-Type: application/json" if I wish to modify the value of this field I use this in the request payload:

    "field_foo_txt": {
        "und": [
            {
                "value": "Test bar",
                "format": "markdown"
            }
        ]
    },

I would expect that using XML in the GET and PUT would behave similarly, but alas it does not.
For example, a GET "Accept: application/xml" on the same node would give a response with the following:

  <field_foo_txt>
    <und is_array="true">
      <item>
        <value>Test foo</value>
        <format>markdown</format>
        <safe_value>&lt;p&gt;Test foo&lt;/p&gt;</safe_value>
      </item>
    </und>
  </field_foo_txt>

But if I PUT "Content-Type: application/xml" with this in my payload:

  <field_foo_txt>
    <und is_array="true">
      <item>
        <value>Test bar</value>
        <format>markdown</format>
      </item>
    </und>
  </field_foo_txt>

I see no change on the node.

To debug this I have used the following patch:

$ git diff
diff --git a/sites/all/modules/custom/services/resources/node_resource.inc b/sites/all/modules/custom/services/resources/node_resource.inc
index 7cc3e0e..dd18ec1 100644
--- a/sites/all/modules/custom/services/resources/node_resource.inc
+++ b/sites/all/modules/custom/services/resources/node_resource.inc
@@ -250,6 +250,8 @@ function _node_resource_create($node) {
   $form_state['values'] = $node;
   $form_state['values']['op'] = variable_get('services_node_save_button_' . $node_type . '_resource_create', t('Save'));
 
+  watchdog("node_resource_debug", print_r($form_state, TRUE));
+
   drupal_form_submit($node_type . '_node_form', $form_state, (object)$node);
 
   if ($errors = form_get_errors()) {

What I find is that the $form_state Array in the working example (JSON) looks like this:

(
    [values] => Array
        (
            [title] => Changed from JSON Services PUT
            [type] => article
            [field_foo_txt] => Array
                (
                    [und] => Array
                        (
                            [0] => Array
                                (
                                    [value] => Test bar
                                    [format] => markdown
                                )

                        )

                )

            [name] => testuser
            [op] => Save
        )
)

But using the non working example (XML) the $form_state Array looks as follows:

(
    [values] => Array
        (
            [title] => Changed from XML Services PUT
            [type] => article
            [field_foo_txt] => SimpleXMLElement Object
                (
                    [und] => SimpleXMLElement Object
                        (
                            [@attributes] => Array
                                (
                                    [is_array] => true
                                )

                            [item] => SimpleXMLElement Object
                                (
                                    [value] => Test bar
                                    [format] => markdown
                                )

                        )

                )
            [name] => testuser
            [op] => Save
        )

)

I hope my explanation makes sense. Can anyone offer some insight here? Also, this issue seems to only affect feilds where the value is an array.
Would this be an issue with the serialization in the first reponse? or an issue with deserialization in the resulting request?

Thanks,
-Ian Page Hands

Your serialization issue has to do with the XML result formatter, not the XML request parser. It is escaping tags that may not be valid. You can customize how results are formatted to change this behavior. For instance, I wrap data that I found like this in CDATA tags (I have to format nested XML documents :*( ).

Can you elaborate here or restate this? I don't quite grok the explanation, but I think it is due to my own lack of experience with the issue at hand.
Thanks.

Your serialization issue has to do with the XML result formatter, not the XML request parser.

I wonder about this statement.

The thing is, after this code is run (RESTServer.inc->parseRequest()):

          if ($handle) {
            $data = call_user_func($parser, $handle);
            fclose($handle);
          }
        }
        return $data;

I think (but I am not sure) the $data that is returned is Content-Type agnostic.
i.e. no matter which content-type is choosen parseRequest() should return a similar data structure.
Right?

And if that is true, I can't see what XML would ever result in an array like:

            [field_foo_txt] => Array
                (
                    [und] => Array
                        (
                            [0] => Array
                                (
                                    [value] => Test bar
                                    [format] => markdown
                                )
                        )
                )

I would always get arrays like:

            [field_foo_txt] => SimpleXMLElement Object
                (
                    [und] => SimpleXMLElement Object
                        (
                            [@attributes] => Array
                                (
                                    [is_array] => true
                                )
                            [item] => SimpleXMLElement Object
                                (
                                    [value] => Test bar
                                    [format] => markdown
                                )
                        )
                )

And the second array is not acceptable.
Am I right in my assumption? or again, am I missing something.

For what it is worth I came up with and am using this patch for servers/rest_server/includes/RESTServer.inc
The patch correctly unmarshals the XML so that Services accepts the same style/format of XML payload that Services sends down.

Please let me know if this is not the desired solution, or if there is some bug in the algorithm.
Thanks,
-Ian Page Hands

i don't mind the patch, but it needs a lot of work.

Theres watchdog statements that run regardless of if the endpoint is in the debug mode, and you have really commented anything your doing.

D'OH that watchdog statement was left over from development / unintentional. Here is a new patch without the debug statements and commented code.