Forum OpenACS Q&A: XML RPC Validator

1: XML RPC Validator

Posted by Iuri Sampaio on 09/17/16 06:10 PM

Hi there,

Does anyone know where XML-RPC validator is nowadays? (http://validator.xmlrpc.com/ )

Best wishes

2: Re: XML RPC Validator (response to 1)

Posted by Iuri Sampaio on 09/17/16 06:16 PM

After have googled it, I found http://xmlrpc.eritreo.it/

I'm going start debugging my xml-rpc instance. I'm willing to contribute to the package. So far, what I've seen about README.txt and troubleshoot cases, they need documentation.

Best wishes

3: Re: XML RPC Validator (response to 1)

Posted by Iuri Sampaio on 09/17/16 06:35 PM

Unfortunately http://xmlrpc.eritreo.it/ is an Wordpress validator. It validates PHP only.

Does anyone know a XML-RPC OpenACS validator?

4: Re: XML RPC Validator (response to 1)

Posted by Antonio Pisano on 09/18/16 12:33 AM

Hello Iuri,

I am no XML-RPC expert, but from some brief search I could find that the original website for the validator is still there: http://www.xmlrpc.com/. However, seems like all the relevant links are dead... maybe you could try contacting the people that are paying for that website and ask them what is happening...

About the one for Worpress, this is a link from the author explaining why he came out with the idea https://daniloercoli.com/2012/05/15/wordpress-xml-rpc-endpoint-validator/

Probably more interesting, this is the code of the thing on Github https://github.com/daniloercoli/WordPress-XML-RPC-Validator
If you see the readme, seems like the validator works in two steps. First is quite generic and -should- apply to any implementation (as far as I understand). Second step seems more Wordpress-specific, as it looks for a user profile, uploads stuff etc.

My two cents are to first see if the original, or equivalent validator is still accessible somewhere, as website or source, otherwise you could either fiddle with the one for wordpress, or use it as blueprints to build one from scratch (of course only for the generic part).

XML-RPC is an interesting feature IMO, that could be nice revamping. If you're embarking on this I could give some support.

All the best

Antonio

5: Re: XML RPC Validator (response to 1)

Posted by Iuri Sampaio on 09/18/16 11:27 PM

Hello Antonio,
Nice to read your post. Currently I'm working on fundamentals, setting up xml-rpc in a box with Naviserver and OACS 5.9.

I've created a new package (i.e. application) and added a few /tcl/ad-procs with some basic samples, requests and responses such as: authentications, sum() and helloworld() functions;

I'm following the documentation available at xml-rpc/www/doc/index.html. Any help is appreciated.

Once the basics get settle, the goal will be to bring IATA NDC XML standard into OACS as a package library perhaps.

Feel free to register at www.iurix.com. I'll give SWA. At ndc.iurix.com/ you will see the webservice application. The index page calls xml_rpc .

catch {xmlrpc::remote_call www.iurix.com/RPC2 system.add -int 4 -int 44} result

That catch returns a few errors within error.log. Somehow it's related to ns_xml and tdom. I'm still debugging it.

Should we keep this thread as a raw documentation source?

Best wishes

6: Re: XML RPC Validator (response to 5)

Posted by Antonio Pisano on 09/19/16 12:15 AM

Hello Iuri,

yesterday I took the chance to refresh my background on this kind of technologies. I am resuming my findings, sorry if I write things you already know:
- XML-RPC is the ancestor of SOAP, which is a more feature rich specification for this kind of remote calls. I have dealt with SOAP in the past, but didn't know about this. [1]
- XML-RPC is not the most throughput-efficient technology around: XML must be parsed back and forth all the time, with computational and bandwidth overhead. This holds also for SOAP. [1] [2]
- Most if not all the things you can achieve with XML-RPC/SOAP could be done by a simple HTTP API, or better by a RESTful webservice [1] [2] [3]
- HTTP API is not a RESTful webservice [4] [5]

This brought to me the following questions/considerations I want to debate with you (and maybe others) before we proceed:
- is XML-RPC a requirement for you? I mean, do you have to interact with applications that speak XML-RPC only? Why don't go with plain HTTP calls?
- as we are considering to revamp this old package, shouldn't we go all the way down including also SOAP in the mix?

More specifical to your problem:
- XML-RPC package relies on ns_xml module, which I don't know. Is it available for naviserver? How does it differ from tdom?

[1] https://en.wikipedia.org/wiki/SOAP
[2] https://en.wikipedia.org/wiki/XML-RPC
[3] https://web.archive.org/web/20130511053512/http://joncanady.com/blog/2010/01/14/if-you-have-rest-why-xml-rpc/
[4] http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
[5] https://en.wikipedia.org/wiki/HATEOAS

Antonio

7: Re: XML RPC Validator (response to 1)

Posted by Iuri Sampaio on 09/20/16 04:29 AM

Antonio,

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.

[1] https://en.wikipedia.org/wiki/SOAP
[3]https://web.archive.org/web/20130511053512/http://joncanady.com/blog/2010/01/14/if-you-have-rest-why-xml-rpc/
[4] http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

Best wishes

8: Re: XML RPC Validator (response to 7)

Posted by Antonio Pisano on 09/21/16 12:03 PM

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

9: Re: XML RPC Validator (response to 1)

Posted by Brian Fenton on 09/21/16 01:41 PM

Hi Iuri

I have quite a bit of experience with SOAP, and believe me, you do not want to go there unless you really have no choice. It's really hell.

I think a good solution for you is the Project Open REST api http://www.project-open.com/en/package-intranet-rest

best wishes
Brian
PS have these forums changed recently? I see the Reply to a message link has been replaced with a Forward button. The threading is gone too, I think.