Duplicate of Services Module?

plus it is also a duplicate of the http://drupal.org/project/webservices which has the same maintainer.

Guys,

both modules (Services and Web Services, which im the maintainer) dont aim the same problem. Both are web services SERVERS. They allow you to other people access your Drupal site's resources ("other sites -> Drupal").

This module is designed to be for web services' CLIENTS ("your Drupal site -> other sites"). Its for people that what to develop modules that access other sites, like Twitter, Google Docs/Contacts/Gmail, Flickr or Amazon AWS. Its a common API for describing authentication methods, input and output conversions and services.

There are also some features included:
* Im working with Wolfgang to integrate it with Rules module, so the same Rules' actions can be easily exported as services.
* Web Services module (the server side) for D7 will need this module.

regards,

massa

How is Web Services API different from Services?
Wouldn't it be better to write modules that provide APIs through Services' service API than making an entirely new module?

Please explain because I am as confused as everyone else.

Jakob,

This module is nothing related to those who want to PROVIDE services. Its for those who want to CONSUME services. They dont overlap in 99% of the things, in fact, they can co-exist in the same site.

regards,

massa

PS: Web Services module, however, does collide.

PS2: marking as fixed. Feel free to reopen it if the module scope is not clear.

PS: Web Services module, however, does collide - seems to indicate that this can be achieved in a different way rather than as a seperate module.

Marc,

THIS module is not related. THIS module is to help most of modules list here that USES some kind of web service. Stop comparing it to services provider modules. Post any complain against Web Services module in this issue.

Its a helper API that will allow Twitter module, for example, call the service using an small code as:

try {
  $server = server_create();
  $parameters = array(
    'id' => 1234,
  );
  $result = $server->call(new service_getMyTweets, $parameters);
  // do stuff with $result;
}
  catch (Exception $e) {
  drupal_set_message($e->getMessage(), 'error');
}

And also automatically enable it into Rules, Views and Bulk operation modules. And since its for D7 only (or initially), its designed to be small and fast enough to be incorporated on Drupal Core in order to be used by OpenID, XML-RPC and possibly Status Update modules.

regards,

massa

brmassa: In that case I think this module is misnamed. Call it "Web Services Client API" instead. "Web Services API" gives the impression that the module provides a web service API which external services can use.

Jakob,

yes. maybe you are right. I will think about changing the module's name once I finish my first prototype.

regards,

massa

Adrian,

thanks. no problem.

I already started the conversation with Wolfgang "fago" (Rules module) and Karim "kratib" (Views Bulk Operations), and its on my plans to contact Earl "merlinofchaos" regarding an standard APIs for actions/triggers.

The problem on developing for D6 is that all the modules have an tested and stablish version. The new API will take time and when ready, D7 will be available. Also, all web services client modules (Twitter, Google stuff, Flickr, etc) already implemented their own methods, and unifying under a new API now is not realistic goal. Note that we might backport it to D6, yes (at least its in our plans).

regards,

massa

I have to add my voice to 4drian's. Looking forward to seeing how this module is developed further!

Massa,

How much overlap is there with this module?

http://drupal.org/project/soapclient

Subscribe.

Becoming more and more interested in brmassa's work. I do agree that this module should be renamed ASAP though. solipsist's suggestion is spot on.

Note: 1/4 of my reasoning is about general usability, 3/4 of my reasoning is that you'll silence some of the criticism. The naming issue drives confusion, which is a roadbock in fruitful discussion.

I'd like to see more thought process focused on how this module and your others (web services, oauth ,etc) are all going in a great direction. It'd be great to see more people get behind it.

So yeah, solving the confusion should be a priority.