*sigh* the downside of living in the UK is that all the interesting
conversations happen when you are in the land of nod.

On 6/1/07, Bill de hOra <bill@...> wrote:
>
>  >
>  > On 5/31/07, Bill de hOra <bill@... <mailto:bill%40dehora.net>>
wrote:
>  >  > I've seen arrant nonsense around transactions
>  >
>  ... WWW is the wrong environment for ACID semantics.

Agreed.

Two-phase commit over the web is brittle & highly latent. This is why
WS-Transaction (AT) is a bad idea.

http://en.wikipedia.org/wiki/WS-Transaction

"Long-running" (aka compensatory) transactions are the way to go.

http://en.wikipedia.org/wiki/Long_running_transaction

Regards,
Alan Dean
http://thoughtpad.net/alan-dean

On 01/06/07, Jon Hanna <jon@...> wrote:

<snipped/> Lots of good stuff. Particularly about the audience.

I like the idea.
I think its needed as a resource to point to.
I'm more than willing to help.

I'm unsure  a wiki is right or wrong
though it could be to get a document outline together.

Offer.
I'll buy a website. One year only. See if it works and interest lasts.
I'll edit it.
   <caveat>docbook input please</caveat>
I'm no REST expert, but I've lots of experience putting docbook together.
I'll leave authority for change with this list.

I'm currently unemployed so I have time to get it started.


Who wants to put an outline together?

regards

--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

From Robin Covers pages

REST and Web Services in WSDL 2.0
Eran Chinthaka, IBM developerWorks

For clients to interact with remotely hosted resources, REpresentational
State Transfer (REST) is fast becoming an alternative for Web services,
especially because REST doesn't require users to understand and use
SOAP. There are ongoing debates as to which one is better suited in
today's highly interactive environment. However, recent efforts,
including Web Services Description Language (WSDL) 2.0, have tried to
give Web services the ability to benefit from REST and use REST concepts.
The HTTP binding specification, available in WSDL 2.0 adjuncts, talks a
lot about this. The first part of this article focuses on how REST is
married to Web services in WSDL 2.0. The second part explains how it's
being implemented in the Apache Web services project. Does WSDL 2.0
enable REST? The motivation of WSDL 2.0 HTTP binding is that it allows
services to have both SOAP and HTTP bindings. The service implementation
deals with processing application data, often represented as an XML
element, and the service doesn't know whether that data came inside a
SOAP envelope, HTTP GET, or HTTP POST. WSDL 2.0 HTTP binding enables
you to expose a service as a resource to be invoked using HTTP methods.
At the same time, you need to understand that HTTP binding doesn't
enable you to implement a full REST style system. This is often debated
by a lot of people, and it all depends on how much you believe in what
REST can deliver.

http://www.ibm.com/developerworks/webservices/library/ws-rest1/



--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

Mike Schinkel wrote:
> It's far easier to develop interoperably for the web than for the
> desktop.
> Why do you think that is?  HTTP, content-types, etc. Basically:
> REST.  IMHO,
> anyway. ;)
>
> Interoperability on desktop apps is not great just as SOAP webservice
> interoperability is not great.  Using REST principles applied
> judiciously to
> the desktop could bring the same interoperability we see on the web
> to the
> desktop.  Secondly, I'm always, always, always pining for some way
> to go
> back to a particular (course grained) point in an application.
> Having that
> point available in an LRL (Local Resource Locator) would be
> wonderful, just
> like having a path I can copy and paste from Windows Explorer to
> file open
> dialogs is wonderful.  Thirdly it could unify the desktop and the
> web and
> eliminate the (in the future more and more) arbitrary distinction
> between
> local and Internet.

A primary issue here is one of loose vs. strong coupling. In a
desktop scenario it is feasible and acceptable to have strong
coupling, because you have a much narrower domain of artifacts and
more control over how those artifacts can behave. In a network
environment you have heterogeneous systems with different
architectures and approaches, so loose coupling is much more likely
to succeed.

People have used distributed technologies to build desktop
applications in the past. For example, there's the CORBA
infrastructure in GNOME, the now defunct Berlin project, and the
various bus- and queue-based inter-application messaging frameworks
in BSD, Solaris, etc. Those technologies, however, are still used in
a very fine-grained, strongly coupled manner.

I do agree with you that there are lessons to be learned from the
interoperability measures and standardisation that has developed in
the web space. If all filesystems were able to store MIME content-
type and other metadata, it would simplify building cross-platform
applications. I'm less sure about your concept of bookmarks for
entire application state identified by "LRLs" or the general
applicability of REST principles to desktop applications.

Since I find it easier to critique an existant document.
Here's my view of how a cookbook might look. Order not considered.


Introduction.
    What its all about
    HTTP, little background
    Why REST
    Alternatives, when to use

HTTP
   Common sense view, applicability, interpretations
   When to use the verbs

Terminology.
   Roys terms mapped to application.

Managing state
   Possiby via simple examples?

Representations.
   Alt media from a single resource, media types etc.

Frameworks.
    ???

Examples.
    Many, simple examples with discussion.


Now what have I missed?

regards

--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

On 6/1/07, Alan Dean <alan.dean@...> wrote:
>  On 6/1/07, Bill de hOra <bill@...> wrote:
>  >  ... WWW is the wrong environment for ACID semantics.
>
>  Agreed.
>
>  Two-phase commit over the web is brittle & highly latent. This is why
>  WS-Transaction (AT) is a bad idea.
>
>  http://en.wikipedia.org/wiki/WS-Transaction
>
>  "Long-running" (aka compensatory) transactions are the way to go.
>
>  http://en.wikipedia.org/wiki/Long_running_transaction

2PC != ACID.

I agree about ACID and WS-AT, but one of my previous transaction
mentors claimed that some form of 2PC is unavoidable for coordination
among independent agents.  He was smarter than me, so I'll tentatively
believe it.

Compensation is extremely difficult in many (maybe most) cases.  Can
you really undo all of the effects of a set of distributed actions?

Another pattern exists that is 2PC but not ACID, variously called
Provisional-Final, Tentative Business Operations (by Pat Helland), or
Escrow.

Does not require compensation or holding locks across phases.

Basic idea is that in the first phase, you update resources
provisionally (implementation cd be a separate entity).  Then in the
2nd phase, if the transaction commits, update finally (update final
entity, e.g. "real" resource).  Or if the transaction cancels, delete
the provisional entity.

In REST, probably uses a separate transaction resource, or at least
that's true of all the RESTful transaction proposals I've seen on this
list or in the recent book.

I don't know why Helland opposes this pattern to 2PC, because it is
2PC, just not ACID.

Probably other patterns cd be found that are 2PC but not ACID, that wd
also work RESTfully.

"Dave Pawson" <dave.pawson@...> writes:

> On 01/06/07, Jon Hanna <jon@...> wrote:
>
> <snipped/> Lots of good stuff. Particularly about the audience.
>
> I like the idea.
> I think its needed as a resource to point to.
> I'm more than willing to help.
>
> I'm unsure  a wiki is right or wrong
> though it could be to get a document outline together.
>
> Offer.
> I'll buy a website. One year only. See if it works and interest lasts.
> I'll edit it.
>   <caveat>docbook input please</caveat>

No thanks. It would have to be easy for me to contribute. I'm
certainly not getting into docbook.

Be good to move this discussion away as soon as possible though. We
don't want to crowd this list out.


--
Nic Ferrier
http://www.tapsellferrier.co.uk

"Dave Pawson" <dave.pawson@...> writes:

> Since I find it easier to critique an existant document.
> Here's my view of how a cookbook might look. Order not considered.
>
>
> Introduction.
>    What its all about
>    HTTP, little background
>    Why REST
>    Alternatives, when to use
>
> HTTP
>   Common sense view, applicability, interpretations
>   When to use the verbs
>
> Terminology.
>   Roys terms mapped to application.
>
> Managing state
>   Possiby via simple examples?
>
> Representations.
>   Alt media from a single resource, media types etc.
>
> Frameworks.
>    ???
>
> Examples.
>    Many, simple examples with discussion.
>
>
> Now what have I missed?

I think we should move this discussion elsewhere.

I've setup a list:

   rest-cookbook-discuss@...

You can also subscribe online:

  
http://sandypit.tapsellferrier.co.uk/cgi-bin/mailman/listinfo/rest-cookbook-disc\
uss


Dave? Can you repost to this list?

--
Nic Ferrier
http://www.tapsellferrier.co.uk

Mike Schinkel wrote:
> Are you assuming I'm Catholic?  If so, you'd be very wrong... :)

No, I'm extending your metaphor.

On a point of order though, let's both agree to avoid analogies to
religious positions. We run a risk of offending someone and I personally
run a risk of enjoying my analogies too much and letting them get the
better of themselves (matches too nicely with one of my other fields of
interest).

John D. Heintz wrote:
> There certainly is client-server. Windows and UNIX provide VFS and
> purely virtual file system abstractions. Plan9 exposes almost
> everything through 9P (a client-server protocol).

And then certain specialised applications deliberately by-pass that.

And they should do. Most apps shouldn't but some should.

And this is where it stops being a client-server constraint and starts
being a client-server service that's there if you want it but not if you
don't.

The same is true and should be true for the rest of desktop computing.

Can experience from REST inform desktop computing - yes, though in my
case probably too much (I'm if anything biased towards using a method
that works on the web since I don't code for the desktop much).

Is the style directly applicable - I think no.

This is also true of other web-like matters (I think Mike's point about
address bars is something where the experience of Windows explorer is
akin to that of the web, but isn't much related to REST).

From the article:

"Does WSDL 2.0 enable REST?
The motivation of WSDL 2.0 HTTP binding is that it allows services to
have both SOAP and HTTP bindings. The service implementation deals
with processing application data, often represented as an XML
element, and the service doesn't know whether that data came inside a
SOAP envelope, HTTP GET, or HTTP POST. WSDL 2.0 HTTP binding enables
you to expose a service as a resource to be invoked using HTTP
methods. At the same time, you need to understand that HTTP binding
doesn't enable you to implement a full REST style system. This is
often debated by a lot of people, and it all depends on how much you
believe in what REST can deliver."

This at least seems to show the author is aware that what WSDL 2
supports is POX over HTTP, not REST.

Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

On Jun 1, 2007, at 10:36 AM, Dave Pawson wrote:

> From Robin Covers pages
>
> REST and Web Services in WSDL 2.0
> Eran Chinthaka, IBM developerWorks
>
> For clients to interact with remotely hosted resources,
> REpresentational
> State Transfer (REST) is fast becoming an alternative for Web
> services,
> especially because REST doesn't require users to understand and use
> SOAP. There are ongoing debates as to which one is better suited in
> today's highly interactive environment. However, recent efforts,
> including Web Services Description Language (WSDL) 2.0, have tried to
> give Web services the ability to benefit from REST and use REST
> concepts.
> The HTTP binding specification, available in WSDL 2.0 adjuncts,
> talks a
> lot about this. The first part of this article focuses on how REST is
> married to Web services in WSDL 2.0. The second part explains how it's
> being implemented in the Apache Web services project. Does WSDL 2.0
> enable REST? The motivation of WSDL 2.0 HTTP binding is that it allows
> services to have both SOAP and HTTP bindings. The service
> implementation
> deals with processing application data, often represented as an XML
> element, and the service doesn't know whether that data came inside a
> SOAP envelope, HTTP GET, or HTTP POST. WSDL 2.0 HTTP binding enables
> you to expose a service as a resource to be invoked using HTTP
> methods.
> At the same time, you need to understand that HTTP binding doesn't
> enable you to implement a full REST style system. This is often
> debated
> by a lot of people, and it all depends on how much you believe in what
> REST can deliver.
>
> http://www.ibm.com/developerworks/webservices/library/ws-rest1/
>
> --
> Dave Pawson
> XSLT XSL-FO FAQ.
> http://www.dpawson.co.uk
>
>

> Basic idea is that in the first phase, you update resources
> provisionally (implementation cd be a separate entity).  Then in the
> 2nd phase, if the transaction commits, update finally (update final
> entity, e.g. "real" resource).  Or if the transaction cancels, delete
> the provisional entity.

Might be more clear if the provisionality was implemented as a
resource property, e.g. "provisional" or "tentative" and then
"committed" or "cancelled".

And again:
http://www.crummy.com/2007/05/31/2

<excerpt>
Transactions of the Transaction Society: Sam and I got a question from
reader Scott Davidson about the famous RESTful transaction design
(quoted at length by Jon Udell here, in case you bought so many copies
of the book that you're now deadlocked trying to decide which one to
look up page 231 in). I think it's worth responding to at length:

     I'm perplexed why your transaction example in Chap. 8 didn't
simply create a transaction resource that included both checking &
savings account as well as the transfer amount w/ a PUT (defining the
resource as XML in the request body). Then you could simply call
/transaction/11a5/commit or even just assume that this is a request to
commit the transaction by default and avoid the 2nd call altogether.
Is there a specific reason why it was not done this way? I can already
see the "REST-haters" rolling their eyes to this three
request/response transaction pattern.

The short answer is that if I'd presented it that way, the
"REST-haters" would have an even better reason to roll their eyes: it
would look like I couldn't think of a resource-oriented way to do
transactions and I'd had to fall back to the RPC style.
</excerpt>

"Today, InfoQ publishes a sample chapter from RESTful Web Services, a
book authored by Leonard Richardson and Sam Ruby. The book covers the
principles of the REST style, and explains how to build RESTful
applications using Ruby on Rails, Restlet (for Java) and Django (for
Python). On this occasion, InfoQ's Stefan Tilkov had a chance to talk
to the authors about their motivations for writing this book and
their views on REST and Web services."

http://www.infoq.com/articles/richardson-ruby-restful-ws

Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

P.S.: Let me know if you believe links like these are inappropriate
for this list.

On 6/1/07, Jon Hanna <jon@...> wrote:
> John D. Heintz wrote:
> > There certainly is client-server. Windows and UNIX provide VFS and
> > purely virtual file system abstractions. Plan9 exposes almost
> > everything through 9P (a client-server protocol).
>
>

And then certain specialised applications deliberately by-pass that.
How exactly do special apps by-pass the VFS? I'd really like some
examples because I don't understand. I know that UnionFS can expose
consistency problems if users modify underlying fs nodes....

>
> And they should do. Most apps shouldn't but some should.

Ok, so if most apps don't, then why invalidate the value of
client-server (9P, local NFS, FUSE, Windows what-ya-ma-callit).

>
> And this is where it stops being a client-server constraint and starts
> being a client-server service that's there if you want it but not if you
> don't.

I thought of a good example: USB.

Today, I plug in a shiny new USB printer, and then have to detect and
install the tightly coupled binary libraries to enable printin. Blech.

Here's a vision of how it could work:
1) I plug in my printer and a new FS tree is exposed (/usb/345)
2) The OS inspects this new tree and crawls it for well supported document types
3) The OS finds a supported application/printer+xml format (at say
/usb/345/printer) with an <print-form href="custom-form"> element
3.1) I'm given a choice to trust this new device service
4) Using that data a new printer is added to my system.
5) When I print something and choose "Print Properties" the
/usb/345/print/custom-form representation is exposed (with full CoD)

While I can tightly couple the code, I see distinct advantages to the
loosely coupled CoD solution.

>
> The same is true and should be true for the rest of desktop computing.

Most desktop computing is tightly coupled with poor interoperability,
your right? So now that we agree on that, how would we take the
lessons learned on the Web and apply them to the desktop?

>
> Can experience from REST inform desktop computing - yes, though in my
> case probably too much (I'm if anything biased towards using a method
> that works on the web since I don't code for the desktop much).
>
> Is the style directly applicable - I think no.

Why don't you suggest how harm could be done by applying these constraints?

>
> This is also true of other web-like matters (I think Mike's point about
> address bars is something where the experience of Windows explorer is
> akin to that of the web, but isn't much related to REST).
>

It is related: Windows Explorer give us just a tiny bit of common
identification and interface.

I can create a shortcut on the desktop (bookmark) to a control panel
icon, or a specific printer. Those are cool URIs.

It all breaks down fast from there though. Why can't I have a shortcut
to a meeting on Friday in outlook? Because that desktop app doesn't
expose uniform identity or interfaces.

>
>
>
> Yahoo! Groups Links
>
>
>
>


--
John D. Heintz
Principal Consultant
New Aspects of Software
Austin, TX
(512) 633-1198

There is an interesting paper that describes this as Promises.
http://www-db.cs.wisc.edu/cidr/cidr2007/papers/cidr07p36.pdf
(I think this link came to me from Pat Helland's blog...)

That paper describes three types of Promise:
1) Named view: promising a specific resource (room 412)
2) Anonymous view: promising $200 from a credit card acct
3) View via properties: promise by properties (non-smoking room, ocean view,...)

John Heintz

On 6/1/07, Bob Haugen <bob.haugen@...> wrote:
> > Basic idea is that in the first phase, you update resources
> > provisionally (implementation cd be a separate entity).  Then in the
> > 2nd phase, if the transaction commits, update finally (update final
> > entity, e.g. "real" resource).  Or if the transaction cancels, delete
> > the provisional entity.
>
> Might be more clear if the provisionality was implemented as a
> resource property, e.g. "provisional" or "tentative" and then
> "committed" or "cancelled".
>
>
>
> Yahoo! Groups Links
>
>
>
>


--
John D. Heintz
Principal Consultant
New Aspects of Software
Austin, TX
(512) 633-1198

On 6/1/07, John D. Heintz <jheintz@...> wrote:
>
> It all breaks down fast from there though. Why can't I have a shortcut
> to a meeting on Friday in outlook? Because that desktop app doesn't
> expose uniform identity or interfaces.

This is a change of topic ... but ...

I wonder if PIM (personal information management) would be an
excellent use-case for REST?

Imagine a world where all the PIM apps out there implemented RESTful
interfaces. Synchronization of appointments, reminders, contacts, etc
would be a doddle. You could instruct an agent app to choose what
synched to where and so on. Dismissal of a reminder on your office to
start driving to a meeting could cause a reminder to be set from your
mobile (cell on the other side of the pond) immediately prior to the
meeting - and the two PIMs need not be the same and need not have
knowledge of one another.

... gazes wistfully into the middle distance ...

Alan

That sounds like a good idea. APP might be the perfect binding glue
for the synchronizations...

On 6/1/07, Alan Dean <alan.dean@...> wrote:
> On 6/1/07, John D. Heintz <jheintz@...> wrote:
> >
> > It all breaks down fast from there though. Why can't I have a shortcut
> > to a meeting on Friday in outlook? Because that desktop app doesn't
> > expose uniform identity or interfaces.
>
> This is a change of topic ... but ...
>
> I wonder if PIM (personal information management) would be an
> excellent use-case for REST?
>
> Imagine a world where all the PIM apps out there implemented RESTful
> interfaces. Synchronization of appointments, reminders, contacts, etc
> would be a doddle. You could instruct an agent app to choose what
> synched to where and so on. Dismissal of a reminder on your office to
> start driving to a meeting could cause a reminder to be set from your
> mobile (cell on the other side of the pond) immediately prior to the
> meeting - and the two PIMs need not be the same and need not have
> knowledge of one another.
>
> ... gazes wistfully into the middle distance ...
>
> Alan
>


--
John D. Heintz
Principal Consultant
New Aspects of Software
Austin, TX
(512) 633-1198

That's one of the projects I am working on. It's called Beatnik, is
written in SwingFX
and is available here:

https://sommer.dev.java.net/source/browse/sommer/trunk/misc/
AddressBook/www/

It's an early prototype.

With many services publishing foaf files (one of them had 15 million
in December) [1],
this is an application that can be immediately useful.

Since the data is out there in RDF formats, which is very flexible,
more flexible than DOM tools are good
for, one has to use some of the 500 rdf tools out there. [2]

The nice thing is it is very powerful. If one makes the right
architectural decisions, one can get some very interesting
features [3].

If people would like to help out on that project, feel free to join.
There is so much to do in this area, there is space for everyone, and
more.

Henry


[1] http://blogs.sun.com/bblfish/entry/15_million_foaf_files
[2] They were 250 when I posted this
      http://blogs.sun.com/bblfish/entry/250_semantic_web_tools
      now there are 500
[3] http://blogs.sun.com/bblfish/entry/beatnik_change_your_mind

On 1 Jun 2007, at 09:23, Alan Dean wrote:

> On 6/1/07, John D. Heintz <jheintz@...> wrote:
> >
> > It all breaks down fast from there though. Why can't I have a
> shortcut
> > to a meeting on Friday in outlook? Because that desktop app doesn't
> > expose uniform identity or interfaces.
>
> This is a change of topic ... but ...
>
> I wonder if PIM (personal information management) would be an
> excellent use-case for REST?
>
> Imagine a world where all the PIM apps out there implemented RESTful
> interfaces. Synchronization of appointments, reminders, contacts, etc
> would be a doddle. You could instruct an agent app to choose what
> synched to where and so on. Dismissal of a reminder on your office to
> start driving to a meeting could cause a reminder to be set from your
> mobile (cell on the other side of the pond) immediately prior to the
> meeting - and the two PIMs need not be the same and need not have
> knowledge of one another.
>
> ... gazes wistfully into the middle distance ...
>
> Alan
>
>

On 6/1/07, Max Voelkel <voelkel@...> wrote:
>
> I always thought the two communites shouldn't ignore each other so much ;-)
>
> [1] http://nepomuk.semanticdesktop.org/xwiki/

I will have a look.

I also feel that the two communities have much in common and suspect
that Danny Ayers would agree. I have been active providing feedback to
the HTTP-in-RDF initiative at the W3C, for example.

Regards,
Alan Dean
http://thoughtpad.net/alan-dean

> A primary issue here is one of loose vs. strong coupling. In
> a desktop scenario it is feasible and acceptable to have
> strong coupling, because you have a much narrower domain of
> artifacts and more control over how those artifacts can
> behave. In a network environment you have heterogeneous
> systems with different architectures and approaches, so loose
> coupling is much more likely to succeed.

Respectfully I think that is a justification that is probably really a
rationalization, the broader industry just not having realized it yet.  I
look at things like the loose coupling of Python and the tight coupling of
C# and ask myself "Are we *really* better with C# than Python?"

Things to ponder.

--
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org
http://atlanta-web.org - http://t.oolicio.us

John D. Heintz wrote:
> Here's a vision of how it could work:
> 1) I plug in my printer and a new FS tree is exposed (/usb/345)
> 2) The OS inspects this new tree and crawls it for well
> supported document types
> 3) The OS finds a supported application/printer+xml format (at say
> /usb/345/printer) with an <print-form href="custom-form"> element
> 3.1) I'm given a choice to trust this new device service
> 4) Using that data a new printer is added to my system.
> 5) When I print something and choose "Print Properties" the
> /usb/345/print/custom-form representation is exposed (with full CoD)
>
> While I can tightly couple the code, I see distinct
> advantages to the loosely coupled CoD solution.

+1

> > This is also true of other web-like matters (I think Mike's point
> > about address bars is something where the experience of Windows
> > explorer is akin to that of the web, but isn't much related
> to REST).
> >
>
> It is related: Windows Explorer give us just a tiny bit of
> common identification and interface.
>
> I can create a shortcut on the desktop (bookmark) to a
> control panel icon, or a specific printer. Those are cool URIs.
>
> It all breaks down fast from there though. Why can't I have a
> shortcut to a meeting on Friday in outlook? Because that
> desktop app doesn't expose uniform identity or interfaces.

You explained it better than I could. Thanks.

--
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org
http://atlanta-web.org - http://t.oolicio.us

Hi all:

To start, this is not about the "Is REST=CRUD?" debate.  This is me asking
how to create a typical CRUD module for a web application that is RESTful.
And forgive the fact that this has probably already been answered 1000 times
before; if it has I haven't seen it.

What started this was someone asked the following on the TurboGears list:

> I've been refactoring my admin interface and trying to get it
> nice and RESTful ( oh the buzzwords! ). As I am new to this
> resting business, I'm wondering, is there a compelling reason
> to need to do:
>
> page/7/edit
> vs
> page/edit/7
>
> The example in the book uses the first, but I'm finding the
> second would be much easier to do with CherryPy.
>
> Thanks helpful gurus!

Several people replied with mechanics of TurboGears but nobody mentioned the
use of the edit verb so I decided to clarify and then realized that, while I
could tell him what not to do (i.e. "don't use verbs"), I couldn't tell him
how to do it correctly.

In the past when I have written such modules I would typically write them
like this:

	 http://examples.com/pages/{page_id}/?mode={mode}

Where {mode} was one of:

	 <nothing>
	 add
	 insert
	 edit
	 update
	 list
	 delete
	 confirm

And maybe a few more.  BTW, these are not that "well designed" URLs, but
it's how I coded before I heavily researched URL concepts.

Note that there are several interesting pairs: "add" and "insert", "edit"
and "update", and "delete" and "confirm"   Both "add" and "edit" displayed a
data entry form whereas "insert" and "update" insert and update from those
forms, respectively, with the latter 302 redirecting to <nothing> (a.k.a.
"show")  and "confirm" displaying a delete confirmation screen with "delete"
performing the actual delete and 301 redirecting to "page/list"  And when
"add" mode was requested it contained {mode} as a hidden field with a value
of "insert." When "edit" mode was requested, the hidden {mode} fields got a
value of "update."  It all works well and good, but I now understand its not
RESTful.

To be RESTful, we GET "page/{page_id}" for display, PUT to "page/{page_id}"
for an update, DELETE "page/{page_id}" for a delete, and GET "page/list" for
a list. But how do we deal with getting an edit form before the PUT?  How do
we handle delete confirmation?  How do we handle requesting a data entry
form designed for a new page (POST to "page/new"?)   Answer both assuming
AJAX and also no AJAX, if you will.

--
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org
http://atlanta-web.org - http://t.oolicio.us

P.S. This soulds like a great cookbook solution and I debated where to
submit the question but defaulted to the larger community to ensure getting
more perspectives.

On Jun 2, 2007, at 11:34 PM, Mike Schinkel wrote:

> To be RESTful, we GET "page/{page_id}" for display, PUT to "page/
> {page_id}"
> for an update, DELETE "page/{page_id}" for a delete, and GET "page/
> list" for
> a list. But how do we deal with getting an edit form before the
> PUT? How do
> we handle delete confirmation? How do we handle requesting a data
> entry
> form designed for a new page (POST to "page/new"?) Answer both
> assuming
> AJAX and also no AJAX, if you will.

FWIW, Rails uses <collection>/<id>;edit to get the edit form, and
links a Javascript function to pop up a confirmation dialog for
DELETE (which is simulated by tunneling a hidden field through POST).
The semicolon has been changed to a slash in the most recent versions
(edge).

Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

MS:

i'm relatively new to REST, but this is what i am doing for CRUD-type
situations:

define a single URI for the object/document/table you are working with:

/users/

GET /users/ returns the list of users
GET /users/{user_id} returns a single user object
POST /users/ with a body creates a new user (and returns a redirect to
the new /user/{user_id} that was created)
PUT /users/{user_id} with a body updates the existing user (optionally
redirect to the same location for the updated object or return no
body)
DELETE /users/{user_id} deletes the existing object

note that there is a single URI (w/ id decoration) and no verbs of any kind.

hope this helps.

mamund


On 6/2/07, Mike Schinkel <mikeschinkel@...> wrote:
> Hi all:
>
> To start, this is not about the "Is REST=CRUD?" debate.  This is me asking
> how to create a typical CRUD module for a web application that is RESTful.
> And forgive the fact that this has probably already been answered 1000 times
> before; if it has I haven't seen it.
>
> What started this was someone asked the following on the TurboGears list:
>
> > I've been refactoring my admin interface and trying to get it
> > nice and RESTful ( oh the buzzwords! ). As I am new to this
> > resting business, I'm wondering, is there a compelling reason
> > to need to do:
> >
> > page/7/edit
> > vs
> > page/edit/7
> >
> > The example in the book uses the first, but I'm finding the
> > second would be much easier to do with CherryPy.
> >
> > Thanks helpful gurus!
>
> Several people replied with mechanics of TurboGears but nobody mentioned the
> use of the edit verb so I decided to clarify and then realized that, while I
> could tell him what not to do (i.e. "don't use verbs"), I couldn't tell him
> how to do it correctly.
>
> In the past when I have written such modules I would typically write them
> like this:
>
>         http://examples.com/pages/{page_id}/?mode={mode}
>
> Where {mode} was one of:
>
>         <nothing>
>         add
>         insert
>         edit
>         update
>         list
>         delete
>         confirm
>
> And maybe a few more.  BTW, these are not that "well designed" URLs, but
> it's how I coded before I heavily researched URL concepts.
>
> Note that there are several interesting pairs: "add" and "insert", "edit"
> and "update", and "delete" and "confirm"   Both "add" and "edit" displayed a
> data entry form whereas "insert" and "update" insert and update from those
> forms, respectively, with the latter 302 redirecting to <nothing> (a.k.a.
> "show")  and "confirm" displaying a delete confirmation screen with "delete"
> performing the actual delete and 301 redirecting to "page/list"  And when
> "add" mode was requested it contained {mode} as a hidden field with a value
> of "insert." When "edit" mode was requested, the hidden {mode} fields got a
> value of "update."  It all works well and good, but I now understand its not
> RESTful.
>
> To be RESTful, we GET "page/{page_id}" for display, PUT to "page/{page_id}"
> for an update, DELETE "page/{page_id}" for a delete, and GET "page/list" for
> a list. But how do we deal with getting an edit form before the PUT?  How do
> we handle delete confirmation?  How do we handle requesting a data entry
> form designed for a new page (POST to "page/new"?)   Answer both assuming
> AJAX and also no AJAX, if you will.
>
> --
> -Mike Schinkel
> http://www.mikeschinkel.com/blogs/
> http://www.welldesignedurls.org
> http://atlanta-web.org - http://t.oolicio.us
>
> P.S. This soulds like a great cookbook solution and I debated where to
> submit the question but defaulted to the larger community to ensure getting
> more perspectives.
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>


--
mca
"In a time of universal deceit, telling the truth becomes a
revolutionary act. " (George Orwell)

I like to think of forms as separate resources from the primary resource.

Off the top of my head (non-AJAX):

GET /users  - lists users, has link to /users/creatorform
GET /users/creatorform - get form to create a new user
     POST form to /users to create user
GET /users/{id} - view user, has links to /users/editorform and
/users/deleterform
GET /users/{id}/editorform - get form to edit a user
     POST form to /users/{id} to update user
GET /users/deleterform - confirms delete
     POST to /users/{id}/deleter to delete user

I'm sure there are arguments to be made for structuring the uri
hierarchy differently or using a semicolon in front of editform.  Note
that I purposely choose to use .../editform rather than .../edit - I
want to be clear that I'm referring to a noun, and not a verb.

I seem to recall the we even split /users/editorform into multiple
forms when we had resources that were too complex or too large to be
edited on a single page.  I don't recall the details, but I seem to
remember it went something like:
    GET /users/{id}/editform1,
    POST form to /users/{id}/editform1 and then get redirected to
/users/{id}/editform2

and so on (I may have this wrong - I forget the details of
transitioning to the second page)

I think the AJAX version would be almost the same except that you'd
PUT to /users/{id} to update and simply DELETE /users/{id} to delete.

--Chuck

On 6/2/07, Mike Schinkel <mikeschinkel@...> wrote:
> Hi all:
>
> To start, this is not about the "Is REST=CRUD?" debate.  This is me asking
> how to create a typical CRUD module for a web application that is RESTful.
> And forgive the fact that this has probably already been answered 1000 times
> before; if it has I haven't seen it.
>
> What started this was someone asked the following on the TurboGears list:
>
> > I've been refactoring my admin interface and trying to get it
> > nice and RESTful ( oh the buzzwords! ). As I am new to this
> > resting business, I'm wondering, is there a compelling reason
> > to need to do:
> >
> > page/7/edit
> > vs
> > page/edit/7
> >
> > The example in the book uses the first, but I'm finding the
> > second would be much easier to do with CherryPy.
> >
> > Thanks helpful gurus!
>
> Several people replied with mechanics of TurboGears but nobody mentioned the
> use of the edit verb so I decided to clarify and then realized that, while I
> could tell him what not to do (i.e. "don't use verbs"), I couldn't tell him
> how to do it correctly.
>
> In the past when I have written such modules I would typically write them
> like this:
>
>         http://examples.com/pages/{page_id}/?mode={mode}
>
> Where {mode} was one of:
>
>         <nothing>
>         add
>         insert
>         edit
>         update
>         list
>         delete
>         confirm
>
> And maybe a few more.  BTW, these are not that "well designed" URLs, but
> it's how I coded before I heavily researched URL concepts.
>
> Note that there are several interesting pairs: "add" and "insert", "edit"
> and "update", and "delete" and "confirm"   Both "add" and "edit" displayed a
> data entry form whereas "insert" and "update" insert and update from those
> forms, respectively, with the latter 302 redirecting to <nothing> (a.k.a.
> "show")  and "confirm" displaying a delete confirmation screen with "delete"
> performing the actual delete and 301 redirecting to "page/list"  And when
> "add" mode was requested it contained {mode} as a hidden field with a value
> of "insert." When "edit" mode was requested, the hidden {mode} fields got a
> value of "update."  It all works well and good, but I now understand its not
> RESTful.
>
> To be RESTful, we GET "page/{page_id}" for display, PUT to "page/{page_id}"
> for an update, DELETE "page/{page_id}" for a delete, and GET "page/list" for
> a list. But how do we deal with getting an edit form before the PUT?  How do
> we handle delete confirmation?  How do we handle requesting a data entry
> form designed for a new page (POST to "page/new"?)   Answer both assuming
> AJAX and also no AJAX, if you will.
>
> --
> -Mike Schinkel
> http://www.mikeschinkel.com/blogs/
> http://www.welldesignedurls.org
> http://atlanta-web.org - http://t.oolicio.us
>
> P.S. This soulds like a great cookbook solution and I debated where to
> submit the question but defaulted to the larger community to ensure getting
> more perspectives.
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>

On 5/28/07, Bill de hOra <bill@...> wrote:
>
>  I think one reason is that without conneg, you end up providing a URI
>  for each supported format, and URI proliferation is hardly a good thing.
>  A few systems do that now; the Zimbra API would be one, moinmoin is
>  another. Here's a simple example:
>
>  xhtml:
> 
<http://www.citizensinformation.ie/categories/money-and-tax/tax/duties-and-vat/s\
tamp-duty-on-financial-cards>
>
>  atom:
> 
<http://www.citizensinformation.ie/categories/money-and-tax/tax/duties-and-vat/s\
tamp-duty-on-financial-cards/entry.xml>
>

Is there any precedent or value in combining the techniques? I guess
that would mean issuing a redirect in response to the negotiation
headers.

Using the above example, perhaps if a client requests the xhtml
document but prefers or only accepts atom, the server responds with a
303 and a location header pointing to the atom document.

-Ross

Mike,
This doesn't answer your question directly but it's a way to implement the
situation and can be used in CherryPy quite easily:

http://routes.groovie.org/manual.html#restful-services

It can be used AJAXian or not, of course, depending on how you implement it.

Scott

Mike Schinkel wrote:
> Hi all:
>
> To start, this is not about the "Is REST=CRUD?" debate.  This is me asking
> how to create a typical CRUD module for a web application that is RESTful.
> And forgive the fact that this has probably already been answered 1000 times
> before; if it has I haven't seen it.
>
> What started this was someone asked the following on the TurboGears list:
>
>> I've been refactoring my admin interface and trying to get it
>> nice and RESTful ( oh the buzzwords! ). As I am new to this
>> resting business, I'm wondering, is there a compelling reason
>> to need to do:
>>
>> page/7/edit
>> vs
>> page/edit/7
>>
>> The example in the book uses the first, but I'm finding the
>> second would be much easier to do with CherryPy.
>>
>> Thanks helpful gurus!
>
> Several people replied with mechanics of TurboGears but nobody mentioned the
> use of the edit verb so I decided to clarify and then realized that, while I
> could tell him what not to do (i.e. "don't use verbs"), I couldn't tell him
> how to do it correctly.
>
> In the past when I have written such modules I would typically write them
> like this:
>
>  http://examples.com/pages/{page_id}/?mode={mode}
>
> Where {mode} was one of:
>
>  <nothing>
>  add
>  insert
>  edit
>  update
>  list
>  delete
>  confirm
>
> And maybe a few more.  BTW, these are not that "well designed" URLs, but
> it's how I coded before I heavily researched URL concepts.
>
> Note that there are several interesting pairs: "add" and "insert", "edit"
> and "update", and "delete" and "confirm"   Both "add" and "edit" displayed a
> data entry form whereas "insert" and "update" insert and update from those
> forms, respectively, with the latter 302 redirecting to <nothing> (a.k.a.
> "show")  and "confirm" displaying a delete confirmation screen with "delete"
> performing the actual delete and 301 redirecting to "page/list"  And when
> "add" mode was requested it contained {mode} as a hidden field with a value
> of "insert." When "edit" mode was requested, the hidden {mode} fields got a
> value of "update."  It all works well and good, but I now understand its not
> RESTful.
>
> To be RESTful, we GET "page/{page_id}" for display, PUT to "page/{page_id}"
> for an update, DELETE "page/{page_id}" for a delete, and GET "page/list" for
> a list. But how do we deal with getting an edit form before the PUT?  How do
> we handle delete confirmation?  How do we handle requesting a data entry
> form designed for a new page (POST to "page/new"?)   Answer both assuming
> AJAX and also no AJAX, if you will.
>

On 6/1/07, Stefan Tilkov <stefan.tilkov@...> wrote:
>  From the article:
>
> "Does WSDL 2.0 enable REST?
> The motivation of WSDL 2.0 HTTP binding is that it allows services to
> have both SOAP and HTTP bindings. The service implementation deals
> with processing application data, often represented as an XML
> element, and the service doesn't know whether that data came inside a
> SOAP envelope, HTTP GET, or HTTP POST. WSDL 2.0 HTTP binding enables
> you to expose a service as a resource to be invoked using HTTP
> methods. At the same time, you need to understand that HTTP binding
> doesn't enable you to implement a full REST style system. This is
> often debated by a lot of people, and it all depends on how much you
> believe in what REST can deliver."
>
> This at least seems to show the author is aware that what WSDL 2
> supports is POX over HTTP, not REST.

Eran is one of the Axis2 team...he's probably implemented that very feature.

On 5/25/07, Scott Chapman <scott_list@...> wrote:
>
> The bigger question that I'm wrestling with is, "How far do you take the
>  mapping of complex queries to the RESTful URL paradigm?"  I.e. if you have a
>  query, "SELECT post_id FROM posts WHERE year(post_date) = 2007 and
>  mont(post_date) = 4" how do you map that to RESTful URL's?
>  This gets  arbitrarily complex.
>  REST doesn't look like it was made to do a full mapping of URL's to SQL.

That is correct, mostly because you are starting from the wrong end
of the problem: "I have SQL, how do I 'map' that into HTTP".

Instead you should be starting with a RESTful model of your service:

   http://bitworking.org/news/How_to_create_a_REST_Protocol

And then build out those resources, which may require writing
some SQL.

    -joe

--
Joe Gregorio        http://bitworking.org