Forum OpenACS Q&A: Re: XML RPC Validator
XML-RPC is not mandatory. I didn't know that XML-RPC was the predecessor of SOAP. Neither that XML-RPC had poor performance, causing computational and bandwidth overhead.
Therefore, I'll forget about xml-rpc and let's move forward using SOAP. Even though, instead of HTTP API, I'd rather to use RESTful. What do you suggest?
I'll read those references get us in the same page.
I had confirmation from collegues that xml-rpc package is in use here since a while for some automatic synchonization. I've checked the differences with vanilla package from cvs and seems like there have been only minor changes to modernize syntax. I could consider committing those changes to the standard, but package should work like it is. Moving to SOAP is a lot more work, and I would not go there unless really required. Seems like this is not your case.
Simplifying a bit, REST is just an architectural style to build webservices, while HTTP API is a technology to build such services. The two concepts are orthogonal: you can have a RESTful webservice not based on HTTP, OR an HTTP API which is not RESTful compliant.
Some more details about your use-case could help giving better indications, but from what I understand you can decide autonomously the way to go. If this is true, then I would apply a Keep It Simple approach and just start from an HTTP API (RESTful or not is for you to decide).
This means you just write regular ad_pages in your system, accepting parameters as usual, then use an HTTP client (cURL from bash? AJAX from a webpage? util::http in OpenACS?...) to call them from a remote source.
If the system calling the webservice is another OpenACS, there are some methods to issue authenticated HTTP calls you can exploit  .  should allow you to authenticate also on another OpenACS instance. Of course you can decide for an authentication mechanism of your own when writing your pages.
Hope this helps