Forum OpenACS Q&A: providing RESTful apis
Is there anything I've missed for providing this kind of service? If it's not already there, is there any interest other than mine? It's not difficult to provide this sort of thing as one-off behavior, but it would be nice to have a general way to do it that handles things like managing API keys, handling input in plain xml or json format, and similarly encoding the results.
I know Frank Bergmann did some work around this for Project Open. It could be worth searching for some of his posts here.
Don added json-procs.tcl to acs-tcl package last August, very handy.
Basically you need an API to register procs that can return a datasource you can convert to/from JSON.
In general, I find you still need to end up writing specific procedures since very few applications use simple objects, although maybe with acs-object-management you could manage different views and provide those with JSON.
OpenACS versions older than this forum thread have indeed some more features that will help when interfacing with web apis:
- a more complete and performant HTTP client interface ()
- tDOM Json support 
I would personally not make it any more complicated than this, unless SOAP or similar friends were a requirement.
I cannot really comment on current status of xml-rpc package
thanks for this advice! Just wondering is there any reason you would recommend TDOM for JSON instead of the json-procs.tcl that Dave mentioned above? http://cvs.openacs.org/browse/OpenACS/openacs-4/packages/acs-tcl/tcl/json-procs.tcl
What might be sometimes harder with tDOM is coping with broken markup or json: even if options are there to mitigate this, tDOM will just not swallow everything you throw at it. In this cases, some hamfisted string parsing does the trick, for me at least. Not sure how tolerant the json-procs are.
In the end, to me there is nothing wrong with the json-procs if they float your boat, is a matter of taste
I have actually used the json-procs.tcl recently to generate JSON, and once you get them working they are good, but I found them a little unintuitive at first.
Please have a quick look at our REST documentation:
The ]po[ REST interface is completely generic.
I have checked, there is one dependency with a ]po[ specific functionality "DynFields" functionality used for "dereferencing" fields which you can ignore, and there are ]po[ specific permission checks in a number of places which you can replace with your own.
You can publish such a modified version using any license you prefer.