REST
REST (REpresentative State Transfer) is a technique for implementing
WebServices using
XML documents plus standard HTTP, using its well-known operations (PUT, GET, POST, DELETE). The service-specific API is created by defining URIs (typically URLs) and
XML documents that model the data structures and requests/responses required.
REST has some very useful properties, e.g. you can use standard firewalls for security, standard caching for performance, while still letting you do everything that
SOAP and
XML-RPC can do.
For more information, see
this excellent article, which includes examples such as how
REST could dramatically simplify the
SOAP-based
UDDI directory service. Other resources are:
The relevance for TWiki is that
REST lets you implement web services (e.g. for
TextFileExport) without adding a completely new technology such as
XmlRpc or
SOAP, and it retains the very useful property that URLs continue to name resources, whether they are web pages or a TWiki data item such as a topic, table item,
WebChanges item, or whatever.
REST should also make it simpler to evolve
WebServices clients and servers without inflexible point-to-point RPC bindings as with
SOAP or
XmlRpc - avoiding such point-to-point integrations is a key trend in large enterprises that can afford 'integration bus' software such as
Tibco Rendezvous.
So... do people think TWiki should go for
SOAP,
REST,
XmlRpc or something else?
--
RichardDonkin - 18 Apr 2002
I just found this topic when my last comment
WikiWorded to it. I would definitely go with
SOAP+REST given the choice, as it's fast becoming a useful reality amongst the blogging community, and I think that Wiki's and Blogs are going to become far closer than they already are...
(
TrackBack to
TWikiOnPhp)
--
MichaelKearns - 14 Jan 2003
My vote goes for simple
REST.
E.g. a POST request to
http://my.si.te/upload/Web/MyTopic
is the missing link for an external editor like
DownUploadForEditing.
In terms of search like e.g.
TWikiSyndication,
TWiki is already pretty close.
A quote from
http://www.xfront.com/REST-Web-Services.html
As a matter of style URLs should not reveal the implementation technique
used. You need to be free to change
your implementation without impacting clients or having misleading URLs.
In other words: hide the
/cgi-bin/twiki
stuff, use
ShorterURLs!
-- 2c by
PeterKlausner 16 Jan 2003
Interesting
article about Amazon's use of REST as well as
SOAP - apparently
REST is far more popular than
SOAP, and 6 times quicker...
--
RichardDonkin - 07 Nov 2003
For an example of
REST with TWiki see
XslWiki and it's
GoogleML web search with content returned to TWiki Edit screen.
Someones view of
REST http://www.prescod.net/rest/mistakes/
--
JohnCoe - 12 Mar 2004
The RSS interface to TWiki can be used as a
XML source of TWiki data.
http://twiki.org/cgi-bin/view/Sandbox/TestRSS?skin=rss&contenttype=text/xml
is a sample source of custom summary of TWiki data. '?skin=rss&contenttype=text/xml' will format the data to
XML.
Attached to
XslSample is a XSL stylesheet that brings the content into a TWiki edit session.
The search in
TestRssBase controls the content of the
XML file.
%SEARCH{"%WIKIUSERNAME%" web="Codev" regex="on" nosearch="on" order="modified" reverse="on" nototal="on" limit="16" format="<item rdf:about=\"%SCRIPTURL%/view%SCRIPTSUFFIX%/$web/$topic\">$n <title>$topic</title>$n <link>%SCRIPTURL%/view%SCRIPTSUFFIX%/$web/$topic?t=$isodate</link>$n <description>$summary</description>$n <dc:date>$isodate</dc:date>$n <dc:contributor>$n <rdf:Description link=\"%SCRIPTURL%/view%SCRIPTSUFFIX%?topic=$wikiusername\">$n <rdf:value>$username</rdf:value>$n </rdf:Description>$n </dc:contributor>$n <wiki:version>$rev</wiki:version>$n <wiki:status>updated</wiki:status>$n <wiki:importance>new</wiki:importance>$n <wiki:diff>%SCRIPTURL%/rdiff%SCRIPTSUFFIX%/$web/$topic</wiki:diff>$n <wiki:history>%SCRIPTURL%/rdiff%SCRIPTSUFFIX%/$web/$topic</wiki:history>$n</item>"}%
This can be used with the other tools in
XslWiki and and can be parsed with [RssWiki.xsl] (currently in
XslSample
--
JohnCoe - 30 Mar 2004
Implementing REST Web Services: Best Practices and Guidelines
The purpose of this article is to summarize some best practices and guidelines for implementing RESTful web services.
- BP: best practice
- G: general guideline
- PS: proposed informal standard
- TIP: implementation tip
- AR: arguably RESTful -- may not be RESTful in the strict sense
--
WillNorris - 29 Aug 2004
It seems to me that
REST would allow plugins that formerly needed add-on scripts (like
VotePlugin) to work as just a plugin, leaving the dangerous footwork to a proven binary.
However, I don't seem to find any code examples of using
REST in a plugin, except for the very basic one in the
EmptyPlugin. Basically I'm looking for "standard" ways to:
- Report success or failure
- err, that's it, the rest seems straightforward
Any pointers?
--
WoutMertens - 18 Dec 2006
We get similar questions quite a lot. What is missing is a
SupplementalDocument on REST, such as a
TWikiRestProgrammingTutorial. Anyone inclined to write one?
--
PeterThoeny - 19 Dec 2006
We have now a new
ConnectByRestPlugin, check it out!
--
PeterThoeny - 2012-05-14