Dear Iuri,
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 [1] [2]. [2] 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
Antonio
[1]http://www.openacs.org/api-doc/proc-view?proc=util%3a%3ahttp%3a%3abasic_auth&source_p=1
[2]http://www.openacs.org/api-doc/proc-view?proc=util%3a%3ahttp%3a%3acookie_auth&source_p=1
