The main problem with the remote API right now is that it is either on or off. There is nothing in between. Because the remote API is very powerful (you can do everything that you could do via the browser and more), we'd like to limit who can use it in order to avoid having to clean up the mess created by reckless or malicious clients. Right now we are thinking about limiting the client IP addresses that can connect to the remote API, and/or limit the access to the service based on user's group memberships or user account permissions.
I'd like to get a better understanding of if and how would you use the remote API for wikis.sun.com, so that we can provide you with the best solution that fits needs of the majority.
Some use cases that come to mind are:
- use an existing command line client to access SunWikis
- a (command line) tool that takes your data in some (XML) format, transforms it to our wiki markup and uploads it to your space
- an application that creates an XYZ report from your database, build server, or other data source and publishes it in a wiki space every night at 3am
- wikification of an existing application a la JDocs
For those who want the technical details:
Each approach of limiting the access that I mentioned above has it's pros and cons. IP address restrictions are suitable for the integration of SunWikis with another web application or web service. On the other hand, it won't work well if the remote API is being accessed from your notebook or desktop that doesn't have a stable IP address.
The restrictions based on group memberships (e.g. only Sun employees can access the API) are very well suited for personal use (e.g. the uploading multiple wiki pages or the renaming of wiki pages in batches), but won't work for web application integration, because employees would have to include their passwords in these applications, which is not a smart thing.
Another problem with both of the previous approaches is that a bug in a client could affect content in all the wiki spaces, because Sun employees have write access to all spaces by default.
A compromise might be to:
- let a user create special account used only for remote access
- add this account to a special group (would be automated)
- grant write access to this account on a per-space basis (requires space admin intervention - the same as how permissions are being granted to external users)
Maybe there is another way to let trust-worthy folks use the remote API - if you know about something, let me now. ;-)
If you can't wait to start using or even writing clients for SunWikis, Atlassian has some good Confluence documentation that might be interesting for you if you have big remote API plans. Most importantly check out the Remote API Specification. Other interesting stuff: Remote API Examples, Confluence SOAP Client in Java