Talk:WikiText Transfer Protocol

The following discussion has been transferred from Meta-Wiki.
Any user names refer to users of that site, who are not necessarily users of MediaWiki.org (even if they share the same username).

I created this article as a specification for a software interface to wikis (with a bias towards MediaWiki). The goal is to have it run on top of HTTP, using many of the mechanisms to send secondary information. Many parts are still unfinished, if you have an idea as to how to that should be implemented, feel free to fill it in accordingly.

Question: why create a new protocol at such a low level when there are many web service standards (like SOAP) or de facto standards (like REST) that provide a way to deal with remote method calls? -- IlyaHaykinson 01:03, 9 Apr 2005 (UTC)

I would very like to see it the way described on the page, not SOAP (or in addition to SOAP.) First, I'm not aware of SOAP implementation for Emacs, which I'm writing a Wikipedia mode for (and BTW, is there a SOAP implementation for PHP?) Second, Wikipedia uses HTTP to operate anyway, so this would probably be easier to implement. -- Paul Pogonyshev 10:46, 3 Jul 2005 (UTC)

I feel very strongly that using HTTP headers to this end is the Wrong Thing. You are mixing your protocol layers in a nasty way. Agents like proxies might take it upon themselves to muck these fields about, and in some environments you won't even be able to generate them. It just screams bad practice.

Personally I really want to see the REST interface first, but it doesn't really matter; so long as the URLs are properly designed all these protocols can coexist. The real priority is probably to get a first protocol revision out there and in use in practice, so that we can learn about these things and design the second revision. In practice that means we should design around the sort of things that appeal to Brion Vibber :-) Ciphergoth 21:02, 5 March 2006 (UTC)

Part of me thinks it's a perverted world we live in where HTTP headers are the 'Wrong Thing' and XML is not, but that's just me being asinine. I think that negotiation of content format and file metadata are exactly what HTTP headers are for. Any proxy that mangles headers arbitrarily does so in obnoxious ignorance, and I don't know that a server environment even exists that allows PHP to run but prevents it from serving custom headers.

To be more civil, I really wouldn't have a problem with REST either. But this is a case where someone's gone to all the trouble of writing a spec for us. And the great thing about starting out with a low-level approach like HTTP headers is that it acts as the ground floor for anything you decide to build on top of it. I think it's far easier to start at HTTP headers and iterate your way up to REST or XML-RPC or whatever than to try to do the whole damn thing at once. Meanwhile, you're getting an API out the door that much sooner, one which requires no external libraries for parsing XML in order to implement. Savetheclocktower 07:33, 6 March 2006 (UTC)

WEBDav

WebDAV is essentially HTTP with the semantics described here. WebDAV allows clients to enumerate, read and edit arbitrary properties on URIs. WebDAV plays nice with proxies. There are WebDAV modes for Windows Explorer (Web Folders), Linux (command line), Firefox. See http://www.webdav.org/ for details.

Why are HTTP headers the wrong thing? Because proxies and firewalls throw them away when they feel like it. The payload is untouched. That is why XML is used, even in webdav.

Here is a request for some properties on a resource. It's taken from the IETF spec text: http://www.webdav.org/specs/rfc2518.html

  PROPFIND  /file HTTP/1.1
  Host: www.foo.bar
  Content-type: text/xml; charset="utf-8"
  Content-Length: xxxx
  
  <?xml version="1.0" encoding="utf-8" ?>
  <D:propfind xmlns:D="DAV:">
    <D:prop xmlns:R="http://www.foo.bar/boxschema/">
         <R:bigbox/>
         <R:author/>
         <R:DingALing/>
         <R:Random/>
    </D:prop>
  </D:propfind>

>>Response

  HTTP/1.1 207 Multi-Status
  Content-Type: text/xml; charset="utf-8"
  Content-Length: xxxx
  
  <?xml version="1.0" encoding="utf-8" ?>
  <D:multistatus xmlns:D="DAV:">
    <D:response>
         <D:href>http://www.foo.bar/file</D:href>
         <D:propstat>
              <D:prop xmlns:R="http://www.foo.bar/boxschema/">
                   <R:bigbox>
                        <R:BoxType>Box type A</R:BoxType>
                   </R:bigbox>
                   <R:author>
                        <R:Name>J.J. Johnson</R:Name>
                   </R:author>
              </D:prop>
              <D:status>HTTP/1.1 200 OK</D:status>
         </D:propstat>
         <D:propstat>
              <D:prop><R:DingALing/><R:Random/></D:prop>
              <D:status>HTTP/1.1 403 Forbidden</D:status>
              <D:responsedescription> The user does not have access to the DingALing property.
              </D:responsedescription>
         </D:propstat>
    </D:response>
    <D:responsedescription> There has been an access violation error.
    </D:responsedescription>
  </D:multistatus>

REST

This is basically using HTTP POST/PUT to update wiki pages. The ATOM publishing protocol draft might give you some ideas on how it works in practice. http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-08.html

The huge benefit of REST and other approaches that build on HTTP is that they leverage the security work in HTTP. You get things like authentication, encryption and so on for free.

XML-RPC

Quite a few of the blogging software packages support an XML-RPC interface for remote posting. It seems like that might be a cleaner method for communicating with a Wiki. It is language independent, simple, and a higher level that will be easier to work with.

Plus it already cleanly deals with things like errors and return values. If you use a library like the Apache XML-RPC implementation you are making your remote procedure calls effortlessly.

XML

Whether its SOAP or XML-RPC, the kind of stuff your trying to do would just be easier in XML. XML libraries exist for pretty much any given platform and language. The problem with WTTP is that unlike XML, developers writing applications to use it would have to handle it line-by-line string parsing; with XML there are a myriad of APIs, some create data structures (DOM) or even sends events of encountered tags on-the-fly (SAX). On an even higher level, there are libraries for SOAP which create API's automatically. WTTP calls for some sort of libwttp to be created; seems like a reinvention of the wheel. --Eean 04:36, 20 March 2006 (UTC)

End of content from meta.wikimedia.org.
Note that the above conversation may have been edited or added to since the transfer. If in doubt, check the edit history.