It's very common for REST Services to have global parameters such as apikey or uid, pwd parameters. These parameters are always passed to all service operations, so it would be very useful to have these global parameters configurable at service level instead of operation level.

The initial idea could be allow the WebServiceDescription object to alter the settings form and handle form submit.

Comments

klausi’s picture

Yes, sounds like a good idea. wsclient_rest.module should save those parameters in $service->settings['global parameters'] or something similar. It has to alter the web service description form to add a similar global parameter input area as for operation parameters. Then it has to check on each operation call if global parameters exist and add them accordingly. Should be pretty straight forward.

The only thing that concerns me is the additional bloat on the form, maybe we should place it in a fieldset or on a separate page.

Anyway, patches welcome.

webmasterkai’s picture

Subscribing. I'll work with nquocbao to submit a patch.

nquocbao’s picture

StatusFileSize
new2.65 KB

Hi All,

Here is the first patch. I use $service->settings['global parameters'], but I think we will have to rework with entity types again. It would be better if we use $service->global_parameters instead.

I intend to include a sample service to demonstrate this feature. Any idea what kind of service I should use as example ?

klausi’s picture

Title: Global parameters in REST client » Global parameters for all operations of a service
Status: Active » Needs work
+++ b/wsclient.inc
@@ -72,6 +72,16 @@ class WSClientServiceDescription extends Entity {
     }
+    ¶

trailing white space

+++ b/wsclient_ui/wsclient_ui.inc
@@ -59,6 +59,25 @@ function wsclient_service_form($form, &$form_state, $service, $op = 'edit') {
+    // global variables table

is a bit confusing. what about "Input for global service parameters"?

You have implemented it for all service types, so I updated the issue title.

Do we want to integrate this in Rules as well? Should the global parameters of an operation be exposed in the Rules action as well so that they could be overridden?

Should we even allow overriding of global service parameters? We could just always rely on the provided default values.

Why would it be better to use $service->global_parameters? We would have to add a DB column to the wsclient_descriptions table then.

nquocbao’s picture

Yeah, i made it for all services.

I think it would be better if we allow user to override the global variables. In Google API for example, they would surely want to override the apikey parameters, wsclient only provide the interface and should not concern about parameter values.

I prefer to have the definition in global_parameters because in this way we can separate the definition with setting. I would only use setting to store value only, not definition. I actually think we should use both global_parameters and settings, in this case user can revert default value for a parameter back (only this parameter, not the whole service). If you agree, I will continue with this patch to add global_parameters

For Rules, I don't have much experience. What kind of actions or condition should we expose to rules regarding global parameters ?

nquocbao’s picture

StatusFileSize
new3.95 KB

Here is the second patch. I add global_parameters columns to the schema and add a hook_update too. Only one small concern with the way I merge the value from service edit form to service entity, don't really feel right about this. You can check in wsclient_ui.inc, line 187-197

Other than that, I think it's good to go.

klausi’s picture

I get this error after updating: "Warning: unserialize() expects parameter 1 to be string, array given in EntityAPIController->load() (line 211 of /home/klausi/workspace/entity/includes/entity.controller.inc)." I guess you will have to insert an empty serialized array as default in the update function, for already existing services in the system.

+++ b/wsclient.install
@@ -160,3 +166,15 @@ function wsclient_update_7100() {
+ * Add global_parameters column ¶

trailing white space.

nquocbao’s picture

I just try to revert the module back to original version on my computer, create some service and enable example services, then apply the patch and run update.php. But I don't get this warning.

I'm using entity 1.0-beta-10 and the default NULL is safe for serialization right ? Can you help me double check on this issue ?

nquocbao’s picture

Also, I'm using default Drupal distro, version 7.8

webmasterkai’s picture

I'm not seeing the warning after applying the patch and running update.php I've tried a couple of the example services. Is the warning happening on a specific page or while running a specific service? I am running the latest dev version of entity however.

klausi’s picture

Ok, I could not reproduce my error from above, so that should be ok. Trailing white spaces still need to be fixed. All comments should start capitalized and end with a "."

I tested the patch, but could not add any global parameters in the UI. You only add the form elements if global parameters already exist, why?

Then I think we do not need so many columns for global parameters, only "name" and "default value" are relevant. I think we should keep it simple and only allow primitive string global parameters for now, so remove "data type", "multiple" and "required" as they do not make sense here. Also "weight" can be left out.

+++ b/wsclient_ui/wsclient_ui.inc
@@ -164,6 +183,18 @@ function wsclient_service_form($form, &$form_state, $service, $op = 'edit') {
+      $service->global_parameters[$param] = $value;
+      $service->global_parameters[$param]['default value'] = $value['default_value'];
+      unset($service->global_parameters[$param]['default_value']);

why do you need this 3 lines? why can't you just save the form values as they are?

And you should add to the description text of global parameters that they will passed to every single operation in this service description.

nquocbao’s picture

Ok klausi, I will roll out a patch to resolve theses.

+++ b/wsclient_ui/wsclient_ui.inc
@@ -164,6 +183,18 @@ function wsclient_service_form($form, &$form_state, $service, $op = 'edit') {
+      $service->global_parameters[$param] = $value;
+      $service->global_parameters[$param]['default value'] = $value['default_value'];
+      unset($service->global_parameters[$param]['default_value']);

Because the definition array and submitted array is different. You can see "default value" vs "default_value". Do you have any suggestion for that ?

nquocbao’s picture

StatusFileSize
new8.57 KB

Here is the new patch. Whitespaces are trimmed, user will be able to add new global parameters and global parameters now contains only name and default value. Hope this is fine for now.

klausi’s picture

+++ b/wsclient.inc
@@ -13,6 +13,7 @@ class WSClientServiceDescription extends Entity {
+  public $global_parameters = array();

class properties should use lowerCamel naming.

+++ b/wsclient.inc
@@ -559,4 +568,4 @@ class WSClientException extends Exception {
-}
+}
\ No newline at end of file

Files should end with the \n character.

+++ b/wsclient_ui/wsclient_ui.inc
@@ -59,6 +59,37 @@ function wsclient_service_form($form, &$form_state, $service, $op = 'edit') {
+    $datatypes = wsclient_ui_types(TRUE);

You don't need the data types anymore, right?

When I create a new REST service I get the following PHP errors:
Notice: Undefined index: global_parameters in wsclient_service_form_submit() (line 201 of /home/klausi/workspace/wsclient/wsclient_ui/wsclient_ui.inc).
Warning: Invalid argument supplied for foreach() in wsclient_service_form_submit() (line 201 of /home/klausi/workspace/wsclient/wsclient_ui/wsclient_ui.inc).

"Specify the global parameters for the services. Global parameters will override the value of operation paramter if parameter value is empty." should be "Specify the global parameters for the service. Global parameters will be used if the value of an operation parameter with the same name is empty."

I think the operations and the data types of a service a more important, so I think the global parameters should come last in the form.

And don't forget to set the status to "neeeds review" if you provide a new patch.

nquocbao’s picture

Status: Needs work » Needs review
StatusFileSize
new8.34 KB

Here is the next patch. I fix the notice error when create new service and update as you suggest. The global parameters are also moved to the bottom of the form.

For global_parameters property, I don't change it to globalParameters because it will add unnecessary code to the module to map properties from database column to object properties. I also see it's used in commerce module too. If you have any suggestion to overcome this, please advise.

Thanks.

klausi’s picture

Status: Needs review » Fixed

Great, committed and attributed to your account: http://drupalcode.org/project/wsclient.git/commit/6c36d97

some changes:
* update 7200 changed to 7101 (make sure to change the number in the system table!)
* empty() for named parameters replaced with !isset()

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.