Consuming Web services shares some functions with providing Web services. I vote for a module that provides a library of bidirectional functions to make it easy for me to write a client exactly matching the provided service. Some matching services of use include:
Version identification so the provider can tell me when I have an out of date client.
Node identification. When I rename a node, I want clients to find the same node. Makes the node id travel around automatically with the title.
Revision identification. When I request information, let me request the latest revision or a specific revision.
Session sync. When I build something in my client, I may use the session record to store intermediate data. Instead of shipping all data back and forwards with every request, provide a service where the server keeps a matching session record and we ship only changes to each other.*
Think of a multipage form where every page has questions that alter the selection and content of subsequent pages. Now place the form in the consuming site and the data in the serving site. You can keep down network traffic by having both sites keep a session record. The session in the provider has to connect to the user in the consumer. The two could swap session ids as the connecting identifiers. A common set of bidirectional functions would make both the consumer module and the provider module fit together easily.
Comments
oauth, I've heard of that before
Oh, that's right, it's here: http://drupal.org/project/oauth
;)
knaddison blog | Morris Animal Foundation
Consumers and providers library
Consuming Web services shares some functions with providing Web services. I vote for a module that provides a library of bidirectional functions to make it easy for me to write a client exactly matching the provided service. Some matching services of use include:
petermoulding.com/web_architect
petermoulding.com/web_architect