Getting WIKI's enabled for API access
ja...@jac2.co.uk
I e-mailed api pbwiki com to try and get my WIKI's enabled. I
didn't know what was involved and I have a couple of WIKI's in V1 &
V2. I sent the e-mail 23 apr 08 and haven't heard back yet. I am
sure that support pointed me toward this e-mail address.
So where should I look for the:
- info on how to API enable my Wiki's?
- docs for the API's V1 & V2?
- examples (unfortunately I am a WIN32 programmer, but want to write
W32 and other add-ons).
TIA and am happy to RTFM, if only I knew where the manual was :-)
JAC.
Nathan Schmidt
Sorry for the confusion - your email got mis-routed by my gmail
filters and I didn't see it until now. The documentation for v1 wikis
is at api.pbwiki.com and for v2 wikis the documentation is on the wiki
itself at {wikiname}.pbwiki.com/api_v2/
v2 wikis have the api enabled by default so you can just start
experimenting. If you'd like the api enabled for a v1 wiki, email me
directly and I'll enable that particular wiki's api.
Best,
-Nathan
--
New office! 1825 South Grant Street, Suite 850 San Mateo 94402
New home! 21677 Rainbow Drive Cupertino 95014
New phone! 415.420.1647
i H
Richard Zidlicky
>
> Hi Jason,
>
> Sorry for the confusion - your email got mis-routed by my gmail
> filters and I didn't see it until now. The documentation for v1 wikis
> is at api.pbwiki.com and for v2 wikis the documentation is on the wiki
> itself at {wikiname}.pbwiki.com/api_v2/
is there some other way to read the docs? Is there a special reason
that they should be readable by logged in admins only?
Finally, I am curious to see what v2 api is but have a v1 wiki with some
applications using v1 api to access it. Can I try both at a time?
Richard
Nathan Schmidt
That's a good point - the original design allowed any logged-in user to see the documentation, but during testing I left in a trap which prevented non-admins from viewing. I've changed the code to get back to that state - that will be active next week (we don't do normal production deploys on Friday). Right now the easiest way to get a feel for the v2 API is to just create a v2 wiki and poke around. The documentation and examples are generated on the fly depending on who's asking, and indicate the various permission levels available, etc.
Here's a list of operations pulled from my wiki just now - the ones marked (unimp) are unimplemented but planned for future expansion. We'll be adding more around adding and changing the wiki's user roster as well.
* No category:
o GetOps
o Help
o Ping
* Meta:
o GetTimes
* Folders:
o DeleteFolder
o GetFolders
o GetPageFolder
o RenameFolder
o SetPageFolder
* Bundle:
o GetBundle
* Pages:
o AppendPage
o DeleteAutosave
o DeletePage (unimp.)
o GetAutosave
o GetCurrentPages
o GetPage
o GetPageRevisions
o GetPageSecurity
o GetPages
o PrependPage
o PutAutosave
o PutPage
o RenamePage
o SetPageLock
o UnlockPage
* Tags:
o AddPageTag
o DeletePageTag
o GetPageTags
o GetTagPages
o GetTags
o SetPageTags
* Internal:
o GetFileListAsHtml
o GetPageListAsHtml
o GetThingbar
* Changes:
o GetChanges (unimp.)
o GetPageChanges (unimp.)
* Users:
o GetUserChanges (unimp.)
o GetUserInfo
o GetUsersInfos
* Files:
o DeleteFile (unimp.)
o GetFile (unimp.)
o GetFiles
o PutFile (unimp.)
o RenameFile (unimp.)
* Tasks:
o GetTaskListAsHtml
* Security:
o SetFolderUserPermission
o SetPageUserPermission
Tim
with 2.0 wikis since there isn't a way to accept the terms of service
or view your pbwiki 1.0 API key even if you get your 2.0 wiki
activated with the 1.0 api.
Hey Richard.. I'm a Win32 programmer as well and have written a
pbwiki.dll that encapsulates the pbwiki 1.0 and 2.0 apis if you're
interested...
you can find the .dll in:
http://copytest.pbwiki.com/f/VisualWiki.zip
if you've got .net then you should be able to explore the objects
exposed there and start playing around..
set your wiki information by setting pbwiki.API.curwiki then start
making calls..
-Tim
>
> - Show quoted text -
Richard Zidlicky
>
> also.. it should be noted that there isn't a way to use the 1.0 API
> with 2.0 wikis since there isn't a way to accept the terms of service
> or view your pbwiki 1.0 API key even if you get your 2.0 wiki
> activated with the 1.0 api.
the whole relation between V1 and V2 looks increasingly complex to
me.
Did I understand the docs right that you can't edit V2 wikis using
old style wikitext syntax but it seems the same wikitext is still
used internally?
I like the ability to fallback to simple methods, for example for
the benefit of simple browsers.
> Hey Richard.. I'm a Win32 programmer as well and have written a
> pbwiki.dll that encapsulates the pbwiki 1.0 and 2.0 apis if you're
> interested...
thanks for the offer, I actually I did not touch win32 in the last
10 years or so :)
I am doing my pbwiki API programming in ruby which works pretty neat
for such simple tasks.
I did not release any code because the v1 API is unfinished and I have
not started with V2 API yet.
Richard
Nathan Schmidt
What we do internally is leave content alone -- saved pages are
considered immutable so we won't go back and rewrite WikiStyle pages
as HTML during a migration from 1.0 to 2.0 on a particular wiki. You
can't edit a 2.0 wiki with WikiStyle text because the page save
handling code expects HTML in the POST.
Meanwhile, since we already have code in place to do WikiStyle to HTML
(for viewing pages in a browser) it's relatively simple for us to do
that transform on-demand, the first time a page is edited with the 2.0
editor. It's much the same mechanism we use now for going back and
forth between WikiStyle and HTML in the 1.0 product.
The problem is that there's really no solid way to consistently
support repeated round trips with full fidelity, and we've decided to
focus on making the best editing experience for HTML rather than
continuing to support both editing paths. I know this is aggravating
for the super-elite early adopters (and yes, I held off with WikiStyle
myself for as long as I could) but editing really has gotten better
lately. The other WYSIWYG pain point, editior loading time, will have
some interesting developments very soon. Simple browsers are probably
better-served by a properly-done mobile/simple version, rather than
shims here and there within the main product codebase. We've been
experimenting with some of these ideas but don't have anything to show
off yet.
-n