The provided argument for parameter is empty

Looks like that would be the equivalent of WSDL schema declaring minOccurs="0". It's part of the spec, so the client should be able to support that fine.
It's nice when there are formal examples to copy from!

I don't know if it's relevant, but the formal schema seems to care about the difference between an element not existing, and an element existing but being empty. Both those (different) cases are captured by the snippet above and treated the same there.
http://www.dimuthu.org/blog/2008/08/18/xml-schema-nillabletrue-vs-minocc...

I suspect a little that the issue I'm facing today is different from the one you are looking at with SOAP, but I've found that when trying to talk REST to some Google APIs
https://developers.google.com/freebase/v1/topic
then I can't allow my service descriptions in the WSClient version of Freebase API to set the unused 'optional' parameters to empty strings, or Google will complain.
EG, if the dateline = "" then the API complains that it isn't a valid date.

Here is what I'm doing about it right now: If the param is optional, and is empty, then don't send it

With this patch in place, all the Google EAT APIs are available to me now.

There remains a small issue of 'what if you want to set an 'optional' parameter to zero. And I'm not sure if my solution tromps on that. But it should be legal for an invocation to have all the optional params isset(), but sum of them set to NULL and ignored ... I think.

It's tricky in the same way this OP is tricky. so I'm dropping it into this issue.

Hi, @dman,

Thanks for all your great work on this.

I've also come across the problem addressed in #7. The (RESTful) Podio API also doesn't like getting empty parameters. Unfortunately the patch didn't work for me because - and I'm not certain if this is something I've boned up on my end, but I don't think so - $arguments is never keyed by the parameter name. What this means is that, after I apply your patch, in the first foreach loop, $info['optional'] && empty($arguments[$param]) will pass for every optional parameter regardless of its value (or whether it has one). What I end up with is an empty $named_arguments array and no parameters.

I'm not entirely certain this is the right way to go, but below is a version of the function that works for me. I reverted back to the original code and then added a single foreach loop. It essentially waits until $named_arguments is all nicely filled out and only then plucks out the empty values.

** Edited: for clarity
** Edited (2014-04-12): Needs an isset()

  public function invoke($operation, array $arguments) {
     
    // ... 
    // ... snipped
    // ...
 
    // Fill in global parameters.
    foreach ($this->global_parameters as $param => $info) {
      if (!isset($named_arguments[$param])) {
        $named_arguments[$param] = $info['default value'];
      }
    }
 
    // Added:
    // Unset any optional parameters with empty values.
    if (isset($this->operations[$operation]['parameter'])) {
      foreach ($this->operations[$operation]['parameter'] as $param => $info) {
        if ($info['optional'] && empty($named_arguments[$param])) {
          unset($named_arguments[$param]);
        }
      }
    }
 
    return $this->endpoint()->call($operation, $named_arguments);
  }

Hope that helps. Cheers -

Patch in #4 applies cleanly and works as advertised.

I'm wondering if it might not be a bad idea to provide the option for operations as well. REST has no official spec so I'd be surprised if devs aren't taking liberties there. Also I think this would bring us closer to a more elegant solution to dealing with outgoing 0/empty/NULL parameters (as discussed in #7-8).

@heddn, if you agree I'd be eager to review the new patch. I'm really stuck on the outgoing params issue and it's only logical to get this change committed first.

Thanks -

Thanks, @heddn. The attached patch includes:

• UI setting 'Allow Null' for data type properties (from @heddn's patch in #4);

• UI setting 'Allow Null' for operation parameters;

• The following addition to invoke() method in WSClientServiceDescription class:

      // Unless explicitly permitted by 'allow null', unset optional parameters
      // with NULL or empty ('') values.
      if (isset($this->operations[$operation]['parameter'])) {
        foreach ($this->operations[$operation]['parameter'] as $param => $info) {
          if ((isset($info['optional']) && $info['optional']) && (!isset($info['allow null']) || !$info['allow null']) && ($named_arguments[$param] === '' || !isset($named_arguments[$param]))) {
            unset($named_arguments[$param]);
          }
        }
      }
  

  (0 and '0' will not be unset.)

It passes all my tests but, again, if someone's got a better way to deal with the params that go out, I'd love to hear it. The code is unusable for me unless I can get rid of the superfluous empty and NULL params.

Cheers -

I've closed #2286265: Remove empty parameters from service requests in favor of this approach. Making NULL values configurable.
If we make the NULL values a "per-parameter" option the solution below won't work. We could consider making it service-wide (the api either accepts null values completely, or it doesn't). I can't envision a service which allows a mix of both really.

$named_arguments = array_filter($named_arguments, 'strlen');

I found the rationale, UI, and tested behaviour in patch #11 to be right on the money.
Running it locally gives desired results naturally, and it looks backwards-compatible.

In testing, the need for the 'required' flag threw me a little, but that was me.

I believe the truth table now is:

* If there is a value, it is always sent.
* if the API is called with the parameter not set, it will not be sent unless it's 'required'
* if called with empty strings, they will NOT be sent unless it's both 'required' and 'send null' is set.
Importantly, even if 'send null' is set, an empty string will not be sent unless it's also required.

I've seen enough wacky web services now to be in favour of the per-parameter UII options, rather than a global per-service flag. (I'm working on Google APIs again today)

I've found the patch from @othermachines to apply clean still, be tidy and only touch the bit of the code it needs to. I'd be happy to put it in, but will wait for either any other thumbs up or if it's still stalled by the time I finish my current project interest I'll commit it myself.

(I only revisit this topic when I get to do academic work as opposed to commercial, so my activity here is periodic only. Sorry we've not been keeping on top of the issues very quickly)

sounds good

committed and pushed
It's now in the -dev branch, will be in the next stable, whenever that is. I think there is some REST2 and Authentication stuff pending that should be rolled in before the next point release.

Thanks everyone for the input and reviews!

Awesome. I've since been sidetracked by other things, but may have to come back and refresh now that things are moving forward again. Thanks -