What does SOAP, XML-RPC and the third (uses simple http post/get with a standard response format) not provide that what you have does provide?

So basically, it's just REST, no?
Humma la beeba la seeba la booba la
Humma la beeba la seeba la bop

So basically, it's just REST, no?

Exactly. Well, not quite *exactly* {grin}. One of the tenants of REST that I'm not comfortable is the HTTP method mappings. For instance I'd be more comfortable having insert and update combined into POST rather than PUT, or separating them respectively out into PUT and POST. Forgive me if I'm combining ideas from the REST wiki and the dissertation, I'm still on my first cup of coffee {grin}.

I'm sure if I had time to go back and re-read Fielding's dissertation I could come up with a few more ways that what's proposed in the original post isn't exactly REST, but his work was certainly one of the inspirations for this proposed method.

-- Douglas Hunter

says dug:


The "protocol" section of the original post begins to describe how to standardize on which HTTP headers to use in which ways to do "simple http post/get" type interactions.

That has already been standardised in WebDAV. If your HTML editors (I'm guessing FrontPage) already support WebDAV, I'd try writing a WebDAV API to your server. Modules like HTTP::DAV or HTTP::Webdav might be of use.

We've done something similar where I work. We have content production software that runs under mod_perl with a SOAP::Lite interface. SOAP was an attractive options for us since it was relatively quick and painless to set up, and we wrote our own desktop application. We've been using it now for a year and a half.

Our desktop client application is written using Wx. We use an ActiveX control for WYSIWYG editing xml documents, and there's a syntax highlighed raw view using Wx::STC (Scintilla)

We'll probably add an FTP or WebDAV api so we can access our repositories from third-party applications. Our SOAP api is fine for our application but it's next to useless if we want to access our repositories from outside our app. Still, we can reuse the code in our FTP/WebDAV api.

I suggest using an open protocol from the beginning.

-- simonflk

The "protocol" section of the original post begins to describe how to standardize on which HTTP headers to use in which ways to do "simple http post/get" type interactions.

That has already been standardised in WebDAV.

I've thought about this a fair bit, and I'm pretty sure I prefer the idea of using existing HTTP methods to view and modify data from a webserver to the extensions provided by WebDAV. For most purposes WebDAV seems like an unnecissary layer (although I understand its usefullness for something like Subversion)

<snipped interesting architecture description that sounded cool />

We'll probably add an FTP or WebDAV api so we can access our repositories from third-party applications. Our SOAP api is fine for our application but it's next to useless if we want to access our repositories from outside our app. Still, we can reuse the code in our FTP/WebDAV api.

I guess I don't think that there should be another API for the problems we're trying to solve (although what you're doing sounds neat). I think HTTP should be enough for viewing and editing content, I just think that most methods of getting the desktop involved are hooey {grin}.

I suggest using an open protocol from the beginning.

Absolutely. Hence the resistance to many of the methods of interacting with the desktop that already exist, and the affinity to HTTP.

Thanks for your response!

-- Douglas Hunter