Hi!

I wanted to propose a *very truly dead simple* REST service
description language and I want it standardized fast ("standard" and
"fast" are two things in different ends, I guess), that's why
simplicity is a must.

Since I can't make changes to the REST Wiki, I've posted it to my web
site. Please visit my site:

http://dev.gauldong.net/

Click on the "Gado-gado" link and see what I have to offer. I joined
the REST mailing lists of yahoo groups to discuss this publicly.
Hopefully a solution will have already been here. But I've searched
google for that and have found nothing which is similar to what I'm
proposing. I also have searched REST mailing lists archives and found
nothing of interest.

Is rest-explore still active? It seems to have been dead for a very
long time.

Hendy Irawan
--
GaulDong - http://www.gauldong.net

I need to restrict access to a web service interface to subscribed
users of the service.

Many of the posts I looked at on this list and the REST wiki refer
to RFC 2617 for further information on implementing http
authentication which, while clarifying my understanding of basic and
digest authentication schemes, does not address their specific usage
in a RESTful application.

Basic authentication seems to be out unless used in conjuction with
SSL, and I'm concerned that use of SSL could hurt scalability of the
application.

Digest authentication looks good, but if I understand correctly,
doesn't appear to be well supported across browsers thereby placing
restrictions on browser-based access (not that this is likely to be
the primary kind of client accessing the service).

Ideally whichever security mechanism is selected to secure the
service it should be relatively easy for developers to work
with.

Would anyone care to share their views/experiences in implementing
security for RESTful web services?

Cheers
Adam

On Mon, 7 Feb 2005 21:18:05 -0500, "Mark Baker" <distobj@...> said:
> If there's something accepting POSTs, then that's something I'd say.

I agree. Try to think whether there isn't any state that
could be usefully returned in response to the GET.

Maybe it would make sense to consider that the thing
you are activating could be a resource, which could have
an boolean 'activated' attribute resource; then you could

PUT /resource/activated
Content-Type: text/plain

t

But maybe you can think of better alternatives yourself.

> There's probably lots of different things that could be returned.
> Is what's POSTed application/x-www-form-urlencoded or
> multipart/form-data?  If so, an HTML form would seem a sensible thing
> to return.

Something I have found to work well is have a resource whose
representation is a 'blank slate' for a particular resource
'class'.

Say you're talking about sales. You have a 'container' or
'category' resource for all the sales resources, e.g. /sales

The HTML representation of /sales links to /sales/new.

The HTML representation of /sales/new would be a form,
which POSTs to /sales .

Jason May <jmay@...> writes:

> I am contemplating a resource that only supports POST, e.g.:
>
> http://www.mysite.com/xyz/activate
>
> POSTing to this resource would return a 201 Created with a link to the
> new resource.  Multiple POSTs are expected; each will create another
> resource.
>
> Doing a GET from the /activate URI makes no sense, since there's
> nothing there.  What's an appropriate error response if a GET is
> attempted?  403 Forbidden?

405.


> Is this a reasonable approach at all?

Yes.


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

On Mon, Feb 07, 2005 at 05:12:27PM -0800, Jason May wrote:
> I am contemplating a resource that only supports POST, e.g.:
>
> http://www.mysite.com/xyz/activate
>
> POSTing to this resource would return a 201 Created with a link to the
> new resource.  Multiple POSTs are expected; each will create another
> resource.
>
> Doing a GET from the /activate URI makes no sense, since there's
> nothing there.

If there's something accepting POSTs, then that's something I'd say.

There's probably lots of different things that could be returned.
Is what's POSTed application/x-www-form-urlencoded or
multipart/form-data?  If so, an HTML form would seem a sensible thing
to return.  If not, and you're dealing with automata, you might consider
an RDF Form[1] like so;

<Container xmlns="http://www.markbaker.ca/2003/rdfforms/"
            xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
            rdf:about="">
   <acceptedMediaType>application/whatever-it-is-you-accept</acceptedMediaType>
</Container>

Worst case, some prose saying "This is a processor of foobar documents"
or some-such, so if somebody finds that URI in the wild they can figure
out what it is.

  [1] http://www.markbaker.ca/2003/05/RDF-Forms/

Mark.
--
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

> I am contemplating a resource that only supports POST, e.g.:
>
> http://www.mysite.com/xyz/activate
>
> POSTing to this resource would return a 201 Created with a
> link to the
> new resource.  Multiple POSTs are expected; each will create another
> resource.
>
> Doing a GET from the /activate URI makes no sense, since there's
> nothing there.  What's an appropriate error response if a GET is
> attempted?  403 Forbidden?
>
> Is this a reasonable approach at all?

While I'll admit to often returning a 500 (by allowing the attempt to
retreive the POSTed data that wasn't POSTed to fail and trigger an error)
one should return 405 Method Not Supported. The accompanying messsage could
describe what the resource does, if that's at all likely to be of use.

Regards,
Jon Hanna
Work: <http://www.selkieweb.com/>
Play: <http://www.hackcraft.net/>
Chat: <irc://irc.freenode.net/selkie>

I am contemplating a resource that only supports POST, e.g.:

http://www.mysite.com/xyz/activate

POSTing to this resource would return a 201 Created with a link to the
new resource.  Multiple POSTs are expected; each will create another
resource.

Doing a GET from the /activate URI makes no sense, since there's
nothing there.  What's an appropriate error response if a GET is
attempted?  403 Forbidden?

Is this a reasonable approach at all?

Thanks,
-Jason

> Does the concept of being 'at a location' imply that the client has
> already issued a request to retrieve a resource such as:
>
> GET /map/x=00001;y=00002
>
> and that the retrieved resource provides a mechanism, such as an
> HTML form, that has an action that has the value of the resource's
> URI, and allows the client to append query parameters to retrieve
> further resources relative to that location?

It implies it, but it's important to note that this is not necessarily the
case.

http://www.google.com/search?q=REST implies that you searched for REST on
google, but obviously if you just go to that URI (e.g. if your mail reader
makes that "clickable") you didn't.

Whatever the server does with the URI must be independent of how it came to
be used.

Regards,
Jon Hanna
Work: <http://www.selkieweb.com/>
Play: <http://www.hackcraft.net/>
Chat: <irc://irc.freenode.net/selkie>

> > So, if you are currently at a location the client might ask how to
> get
> > to another location:
> >
> >  GET
> > /map/x=00001;y=00002?
> destx=00003&desty=00004;centerAbout=route;scale=6000
>
> Forgive me for asking what may appear to be a self-evident question
> concerning the generation of URIs.
>
> Does the concept of being 'at a location' imply that the client has
> already issued a request to retrieve a resource such as:
>
> GET /map/x=00001;y=00002

Yes. It assumes that you are navigating through the data in the same
way that you navigate through linked HTML pages.

> and that the retrieved resource provides a mechanism, such as an
> HTML form, that has an action that has the value of the resource's
> URI, and allows the client to append query parameters to retrieve
> further resources relative to that location?
>
> In this way the path section of the URI would be generated by the
> server, and the query string by the client.
> If this same URI was completely generated by the client, not
> relative to another resource within the path hierarchy, would it be
> more 'correct' to put all parameters including the source location
> coordinates within the query string?

Another way to find a route might be to have a URI for routes.

   GET /route

This resource contains a potentially infinite number of routes from all
sources to all destinations. You then provide parameters to it to
limit the number of routes displayed. Perhaps the source and destination
appear as dropdowns.

   GET /route?source=tadwell&destination=norwich

The URI for a particular route may just be a hierarchy of locations.

   /route/tadwell/bairnsdale/norwich

(The place names are arbitrary and for demonstration only as
  they are more understandable than the XY coords. )

Just an idea,
Donald.

adamratcliffe2004 wrote:

>Forgive me for asking what may appear to be a self-evident question
>concerning the generation of URIs.
>
>Does the concept of being 'at a location' imply that the client has
>already issued a request [...]
>
[...]

>If this same URI was completely generated by the client,
>
Adam,

not sure how much this addresses your needs, but maybe it is helpful in
this context to point out that in a RESTful application (e.g. a Google
search or a purchase at Amazon) the user agent must not (be forced to)
make expectations about previous state changes in the application flow
nor must it (be forced to) have any knowledge about how to generate URIs
for subsequent state changes.

RESTs concept of 'hypertext is the engine of application state' means
that the client advances through the application by traversing
hyperlinks that the server 'offers' in the form of hypertext. IOW, the
server provides options for state changes and now knowledge beyond the
'understanding' of the message MIME type is required of the client.

HTH,

Jan

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


--
Jan Algermissen
Consultant & Programmer
http://jalgermissen.com

> One way of looking at this issue, and its not the only way, is that
> your URIs identify items of interest and by adding a query to the
URI
> you ask a question of that item of interest.

Yes, that feels right to me too :)

>
> So, if you are currently at a location the client might ask how to
get
> to another location:
>
>  GET
> /map/x=00001;y=00002?
destx=00003&desty=00004;centerAbout=route;scale=6000

Forgive me for asking what may appear to be a self-evident question
concerning the generation of URIs.

Does the concept of being 'at a location' imply that the client has
already issued a request to retrieve a resource such as:

GET /map/x=00001;y=00002

and that the retrieved resource provides a mechanism, such as an
HTML form, that has an action that has the value of the resource's
URI, and allows the client to append query parameters to retrieve
further resources relative to that location?

In this way the path section of the URI would be generated by the
server, and the query string by the client.

If this same URI was completely generated by the client, not
relative to another resource within the path hierarchy, would it be
more 'correct' to put all parameters including the source location
coordinates within the query string?

Cheers
Adam

On Thu, 03 Feb 2005 13:19:19 -0800, Jason Diamond <jason@...> wrote:
> Elias Sinderson wrote:
> >  As interesting an approach as this may be, it is a Bad Idea [TM] to
> >  reify HTTP / WebDAV methods, such as DELETE and MOVE, within resource
> >  URIs. This fundamentally subverts the reason for having different
> >  HTTP methods in the first place...
> >
> >  REST as realized by the Web is (thankfully) about more than GET and
> >  POST.
>
> These resources would *only* be used by crippled HTML browsers.
> Programmatic access by developers not using a browser could use the
> appropriate HTTP methods on the actual resources.

> Sandeep said that he "interpreted" POST-s to these "browser specific
> resources" as PUT-s to the actual resources. In fact, theres' no reason
> why you can't actually implement code that does an actual PUT or DELETE
> or whatever to the "real" resource when a POST is made to one of the
> "fake" resources.
>
> This isn't a limitation of the REST architectural style but a limitation
> of some of the tools we have to deal with (I'm considering the browser a
> tool).


Exactly! You can PUT/GET/POST/DELETE on the real resource and this is
what programmatic clients would do and depending on conneg they would
get the appropriate representation. This means that the handling on
the server side is based on uniform semantics and the hacks can be
taken out anytime without affecting its behaviour which is RESTful. I
arrived at this solution after seeing countless implementation when a
web-based server would need new wrapper code around it to make it a
web-service. With my approach (that uses conneg appropraitely) there
is just one codebase that is based on uniform semantics and as a
web-service developer/modeller you think only in terms of REST.

Sandeep Shetty

On Thu, 03 Feb 2005 22:13:56 +0100, Jan Algermissen
> IMHO the form is just another representation of the resource and conneg
> would be the appropriate
> way to tell the server to GET me the form instead of the non-form, or am
> I completely wrong?

This is exactly the same conclusion that I arrived at before I came up
with the hack I mentioned in the other thread. The reason I din't go
with conneg is that the problem would not exist when we have
structured data with proper semantics and REST clients that understand
them and till we get there we have WYSIWYE:
Edithttp://www.oreillynet.com/pub/a/mozilla/2003/10/03/mozile.html

I am currently working on a REST GUI client along the lines of
LiveHTTPheaders for testing and trying out REST based web-services.
Say you have a resource /some-uri-space/xyz and you perform a GET on
it using the REST client and it sent a XML or RDF representation which
you could edit and PUT back to the same resource, similar to how web
services would communicate with each other. I know this is a
simplistic example but this is how I think the semantic web should
work. Where the representations themselves have structure and
semantics and you don't need a Form to create/edit/delete them.

Conneg would play a role here in getting me the representation that my
REST GUI client can provide a editable interface for.

Sandeep Shetty

On Thu, 03 Feb 2005 21:37:16 +0000, Vincent D Murphy <vdm@...> wrote:
> Why not just do a PUT on the real resource whenever you
> receive a POST on the real resource? Having the fake resource
> in the middle seems superfuous to me. All you need is an
> if-then on the server, before you dispatch on the HTTP method
> field.

Which is why I don't have it like this. If in the future I have to
remove the hack I have to go remove all the If-then's in my code or
leave it in there in which case I cannot use the POST method on the
real resource because I'm using it for a hack!

I need the fake resource to cleanly separate the hack from the core of my code.

Sandeep Shetty

> > >  This is similar to how I do it. Say you have a resource:
> > >  some-uri-space/sub-space/xyz I would have another resource
> > >  (some-uri-space/edit/xyz) that would give me a editable
> > >  representation of the above resource.
> [...]
> > I like it. Do you have corresponding URI spaces for delete, rename,
> and other operations?
>
>
> As interesting an approach as this may be, it is a Bad Idea [TM] to
> reify HTTP / WebDAV methods, such as DELETE and MOVE, within resource
> URIs. This fundamentally subverts the reason for having different HTTP
> methods in the first place...
>
These resources aren't modelling the methods, but I believe they are meant
to access user interface artifacts related to the activity of deleting or
moving - like a confirmation page, or selecting a destination, etc. There
are 'ui resources' separate from the 'data resources'.

On Thu, 03 Feb 2005 12:52:38 -0800, Jason Diamond <jason@...> wrote:
> Interesting. Your edit form resources are not subordinates to the actual
> resources you're editing.
>
> This has the advantage that it makes it easy to exclude those resources
> using /robots.txt.


That and it cleanly separates the hack from the rest of my code on the
server side.
Let me explain:
I've mapped URI-spaces to resource-handlers on the server side. So a
PUT to some-uri-space/resource-type-a/xyz means that I want to either
create  or update a resource xyz of type resource-type-a. So i can
discern that anything in the URI-space after
some-uri-space/resource-type-a is a resource of that type. If I have a
resource some-uri-space/resource-type-a/xyz/edit then from what I've
said earlier, I now have to assume that I have a resource /xyz/edit of
type resource-type-a which I think is a pollution of the URI-space
some-uri-space/resource-type-a/. Also, later I can just remove the
mapping to the specific CREATE/EDIT/DELETE resource without touching
the URI-spaces that behave RESTfully. Thats why the CREATE/EDIT/DELETE
Form resources are not subordinates of the actual resource.

> I like it. Do you have corresponding URI spaces for delete, rename, and
> other operations?

Yep. I have something similar for CREATE and DELETE as well, along
with EDIT. RENAME  I don't have.

Sandeep Shetty

On Feb 3, 2005, at 7:55 AM, Vincent D Murphy wrote:

> If anybody asks on rest-discuss about how to do a shopping
> cart in future, this is the URL to show them:
>
> http://www.panic.com/goods/
> (found at http://del.icio.us/url/894a7a9e057590ca902ce9b266f3802c )

Heh, well, it's a nice example even with the cookies -- sometimes
just having the UI to show is enough.  I was asked the question
(for the 100th time) a few weeks ago --- how to build a shopping
cart that follows REST constraints --- and was a bit surprised
that I couldn't find any of my old e-mails on the subject.  I used
it as one the primary examples in talks about the style.

<http://www.ics.uci.edu/~fielding/pubs/dissertation/
evaluation.htm#sec_6_3_4_2>

I did find a related discussion on www-talk

<http://www.webhistory.org/www.lists/www-talk.1995q3/0348.html>

and, lo and behold, there is a response from James Gosling
that is very close

<http://www.webhistory.org/www.lists/www-talk.1995q3/0354.html>

      - behaviour and state needs to be pushed out. Things like
        shopping baskets are easy to do as Java applets. Since
        there's no shared state between the client and server,
        everything is cacheable. The server gets one "put"
        when the customer pushes "buy".

And the message I sent about it here:

<http://groups.yahoo.com/group/rest-discuss/message/3583>


Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>

>>>>> "Vincent" == Vincent D Murphy <vdm@...> writes:

     Vincent> I don't believe in a "cookies are bad" dogma, I just
     Vincent> believe that its useful to know the consequences of using
     Vincent> them from an architecture point of view.

No disagreement here. It's the only thing you can use.

That said, this example's use of cookies is pretty bad.

     Vincent> For example, I think its pretty much impossible to do
     Vincent> useful authentication/authorisation and login/logout
     Vincent> functionality without cookies, because of useless browser
     Vincent> support for HTTP auth. But that doesn't mean there aren't
     Vincent> ways you can win by keeping the rest of your app RESTful
     Vincent> in its design.

There has been a thread on this with some very convincing code that it
is possible. Next time I've to do HTTP auth, I will definitively give
this a try.


     Vincent> Still, reading the code, I think the cookie is there so
     Vincent> the shopping cart can be repopulated after quitting the
     Vincent> browser, or a reload. Pretty orthogonal to maintaining
     Vincent> connection state. A *good* use of cookies, dare I say?

No IMO. If you use a cookie, you would need only one. A session state
identifier. Rest of session variables are stored at the server.


     Vincent> I'll probably study this properly over the weekend to
     Vincent> find out for sure, but I have a hard time seeing how you
     Vincent> couldn't POST a representation of the array of ordered
     Vincent> items.

From an HTTML form and browser? Impossible I would say.

--
Regards,

Berend. (-:

Hi Jason,

You've had plenty of great responses, but I thought I'd give my 2 cents.

You appear to be forgetting that a HTML form, the form you want to use
to edit your resources in the browser, is itself a unique Web resource.

So I'd say that a RESTful way to edit resources through POST and a
browser is to have an edit resource that takes a URL as a querystring
and has a representation of an editable version of your URL resource.

   view - GET http://example.org/myresource
   edit - GET http://example.org/edit?url=/myresource
   save - POST http://example.org/edit?url=/myresource

Whether your edit resource should be POSTable to or your resource
itself, I'm not sure and I don't think it really matters, since POST is
the workhorse of HTTP and left mostly to the author to use as they need.

This method also allows you to return different representations for
editing your resources (for example a HTML form, an XFORMs form, or a
XUL form) by using conneg on your edit resource.

Paul.

Jason Diamond wrote:
>
> Hi.
>
> I'm working on an application that exposes some kind of "item" to its
> users (the actual kind of item isn't important). I want users to be able
> to interact with the application using their browsers (representations
> in HTML) or programmatically (representations in XML).
>
> I'd like the interaction "pattern" to be similar for both types of
> access. (Or maybe that's not something I should want?)
>
> The application has a unique URL for each item it exposes to its users.
> Using a browser, users can GET a URL and see a representation of the
> item. If they want to edit the item, they click the "Edit" button which
> would POST back to the same URL. After modifying the values, they click
> the "Submit" button which POST-s back to the same URL again.
>
> Something seems fishy with this design when compared with how it would
> be done programmatically. A user would GET the URL and receive XML. They
> would then PUT the modified XML to the same URL which would update the item.
>
> Browsers don't support PUT-ing XML, of course. So we have to POST
> multipart/form-data. I don't have a problem with implementing code that
> can extract the necessary bits from XML or multipart/form-data.
>
> It's the intermediate step of POST-ing to the URL to get an editable
> HTML representation of the item that I'm not happy with.
>
> An alternative would be to include a link with a query string parameter
> like "?mode=edit" but that doesn't strike me as being very REST-ful, either.
>
> I know it's possible, but I'm trying to avoid returning HTML containing
> the necessary JavaScript to dynamically transform the initial
> representation into an editable HTML form at the click of a button
> (without making another request).
>
> Thanks in advance.
>
> -- Jason
>
>
>
>
> ------------------------------------------------------------------------
> *Yahoo! Groups Links*
>
>     * To visit your group on the web, go to:
>       http://groups.yahoo.com/group/rest-discuss/
>
>     * To unsubscribe from this group, send an email to:
>       rest-discuss-unsubscribe@yahoogroups.com
>       <mailto:rest-discuss-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>
>     * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>

Vincent D Murphy wrote:

>  On Thu, 03 Feb 2005 13:19:19 -0800, "Jason Diamond"
>
> > Sandeep said that he "interpreted" POST-s to these "browser
> > specific resources" as PUT-s to the actual resources. In fact,
> > theres' no reason why you can't actually implement code that does
> > an actual PUT or DELETE or whatever to the "real" resource when a
> > POST is made to one of the "fake" resources.
>
>  Why not just do a PUT on the real resource whenever you receive a
>  POST on the real resource? Having the fake resource in the middle
>  seems superfuous to me. All you need is an if-then on the server,
>  before you dispatch on the HTTP method field.
>
>  Also, consider that POST encompasses 'processThis' semantics, which
>  are more general-purpose than GET/PUT/DELETE. I think that makes for
>  a more natural fit.

I guess you're right. I think I was just trying to justify creating the
extra resources by giving them more to do. One if-then on the server
wouldn't be bad (and in the web framework I'm using, I wouldn't even
need that).

I was just worried about the "conceptual" overhead of each resource. If
a resource only returned (for GET) and only accepted (for PUT/POST) one
content type, that seems like it would be easier to reason about.

You said in another message that you expose your resources like this:

> /foo/html
> /foo/html_form
> /foo/pdf
> /foo/xml

So you *never* do a GET on /foo? You only PUT, POST, DELETE to it?

-- Jason

On Thu, 3 Feb 2005, Vincent D Murphy wrote:
> I haven't needed conneg so far, because I make every
> representation a resource with its own URI. e.g.
>
> /foo/html
> /foo/html_form
> /foo/pdf
> /foo/xml

I use the same workaround and am reasonably happy with it.  It often makes
good RESTful sense by accident, because depending on content negotiation
makes the URL slightly less useful.

On Thu, 03 Feb 2005 13:19:19 -0800, "Jason Diamond"
<jason@...> said:
> Sandeep said that he "interpreted" POST-s to these "browser specific
> resources" as PUT-s to the actual resources. In fact, theres' no reason
> why you can't actually implement code that does an actual PUT or DELETE
> or whatever to the "real" resource when a POST is made to one of the
> "fake" resources.

Why not just do a PUT on the real resource whenever you
receive a POST on the real resource? Having the fake resource
in the middle seems superfuous to me. All you need is an
if-then on the server, before you dispatch on the HTTP method
field.

Also, consider that POST encompasses 'processThis' semantics,
which are more general-purpose than GET/PUT/DELETE. I think
that makes for a more natural fit.

On Thu, 03 Feb 2005 22:13:56 +0100, "Jan Algermissen"
<jalgermissen@...> said:
> This actually relates to a question I have been having in my head for
> some time:
>
> IMHO the form is just another representation of the resource and conneg
> would be the appropriate
> way to tell the server to GET me the form instead of the non-form, or am
> I completely wrong?

I agree with your statement that the form is just another
representation.

I'm not so sure that you need conneg. I think it would be
enough to split resource metadata in to its own resource.

> The issue with this is that there are no standard headers that allow for
> negotiations of variations on
> MIME types, just for negotiations of the MIME type as such. I would
> actually also need such a
> capability for RDF representations: sometimes I want all statements
> about the GETed resource, sometimes
> I only want for example the statements that tell me what rdfs:label the
> resource has.

Continuing from above, maybe 'Variations on MIME types' here
basically constitutes variation on the resources involved,
because there is a difference between the resource data and
the resource metadata.

I find it easier to cope with this problem by just sticking
resource metadata in a subordinate resource.

Paul James described a similar thought process recently;
you might find it helpful:
http://www.peej.co.uk/thinking/2005/01/restification

> Or is that an inappropriate use of conneg anyhow?

I haven't needed conneg so far, because I make every
representation a resource with its own URI. e.g.

/foo/html
/foo/html_form
/foo/pdf
/foo/xml

Elias Sinderson wrote:

>  As interesting an approach as this may be, it is a Bad Idea [TM] to
>  reify HTTP / WebDAV methods, such as DELETE and MOVE, within resource
>  URIs. This fundamentally subverts the reason for having different
>  HTTP methods in the first place...
>
>  REST as realized by the Web is (thankfully) about more than GET and
>  POST.

These resources would *only* be used by crippled HTML browsers.
Programmatic access by developers not using a browser could use the
appropriate HTTP methods on the actual resources.

Sandeep said that he "interpreted" POST-s to these "browser specific
resources" as PUT-s to the actual resources. In fact, theres' no reason
why you can't actually implement code that does an actual PUT or DELETE
or whatever to the "real" resource when a POST is made to one of the
"fake" resources.

This isn't a limitation of the REST architectural style but a limitation
of some of the tools we have to deal with (I'm considering the browser a
tool).

-- Jason

On Thu, 03 Feb 2005 12:46:46 -0800, "Jason Diamond"
<jason@...> said:
> I was initially POST-ing because GET-ing was returning the non-editable
> representation of the resource. I needed something to help my server
> code distinguish between the when it should return the resource as
> non-editable HTML or as an editable HTML form.

Well, URIs are cheap, so maybe you should distinguish between
two URIs rather than two methods. This is muddying the semantics
of GET and POST in my opinion.

> I've since decided this wasn't the best approach as that means the code
> that handles POST-s for that URL needs to distinguish between the
> "initial" POST when the HTML form is returned and the subsequent POST
> when the form data is submitted.

Agreed.

> Seeing the code get messy made it
> obvious that it wasn't a good design.

Agreed, with the qualification that sometimes code is messy
because your language or environment are inadequate.
e.g. trying to use higher-order procedures in Visual Basic.

> > > An alternative would be to include a link with a query string
> > > parameter like "?mode=edit" but that doesn't strike me as being
> > > very REST-ful, either.
> >
> >  This is mostly RESTful. Just don't mistake 'mode' to mean
> >  'method'. You might want to use 'mode=author' and 'mode=reader' or
> >  some noun-based word.
>
> This is what I switched to using but instead of traditional query string
> parameters, the query string looks like "?edit" or "?delete". I might be
> abusing the query string by doing that, though. I could just as easily
> use an extra path segment.

I think the distinction between putting the verb in a
path segment or a query string segment matters less than
whether you put it in the entity body.

Ideally, you would just put it in the HTTP method field,
if you have tools that let you read and write this value
at either end. Failing that, you have to compromise.
I think putting it in a POSTed entity body (e.g. as a form
field) is less evil than putting it in the URI.

Another option could be using XMLHttpRequest to just
send the correct verb in the HTTP method field, but
I haven't researched that yet.

> Here's some possibilities (with delete thrown into the mix):
>
> - GET example.org/foo - returns representation of foo (HTML or XML
> depending on Accept header)
> - PUT, POST example.org/foo - accepts XML
> - DELETE example.org/foo - deletes foo resource
> - GET example.org/foo?edit - returns HTML form to edit foo
> - GET example.org/foo/edit - using path segment instead of query
> - GET example.org/foo/edit-form - using noun
> - POST example.org/foo/edit-form - accepts multipart/form-data, updates
> foo resource (parent)
> - GET example.org/foo?delete - returns HTML form to confirm delete
> operation
> - GET example.org/foo/delete - using path segment instead of query
> - GET example.org/foo/delete-form - using noun
> - POST example.org/foo/delete-form - deletes foo resource (parent)
>
> I'm not sure I like how POST-ing to a subordinate resource (when using
> path segments instead of query strings) updates and/or deletes the
> parent resource even if it's just a hack to get around the browser's
> limitations. Maybe that's an argument in favor of query strings.

I agree, which is why I have the HTML form in ./html_form POST to ../
(the parent resource). I only ever GET the subordinate resource.

Jason Diamond wrote:

> Here's some possibilities (with delete thrown into the mix):
>
>- GET example.org/foo - returns representation of foo (HTML or XML
>depending on Accept header)
>- PUT, POST example.org/foo - accepts XML
>- DELETE example.org/foo - deletes foo resource
>- GET example.org/foo?edit - returns HTML form to edit foo
>- GET example.org/foo/edit - using path segment instead of query
>- GET example.org/foo/edit-form - using noun
>
>
>Any suggestions?
>
>
This actually relates to a question I have been having in my head for
some time:

IMHO the form is just another representation of the resource and conneg
would be the appropriate
way to tell the server to GET me the form instead of the non-form, or am
I completely wrong?

The issue with this is that there are no standard headers that allow for
negotiations of variations on
MIME types, just for negotiations of the MIME type as such. I would
actually also need such a
capability for RDF representations: sometimes I want all statements
about the GETed resource, sometimes
I only want for example the statements that tell me what rdfs:label the
resource has.

As I am doing this in a controlled and closed environment, I
experimented with additional proprietary
headers such as

GET /foo HTTP 1.0

Accept: application/rdf+xml
Limit-Schema: http://www.w3.org/2000/01/rdf-schema#

I am having trouble figuring out what the right (intended) way for
definitions of extension headers is,
when I want to take this approach out into the wilde.

If someone could direct me to *the* specs for doing this, that would be
of great help.

Or is that an inappropriate use of conneg anyhow?

Thanks,

Jan

--- In rest-discuss@yahoogroups.com, Jason Diamond <jason@i...> wrote:
> Sandeep Shetty wrote:
>
> >  This is similar to how I do it. Say you have a resource:
> >  some-uri-space/sub-space/xyz I would have another resource
> >  (some-uri-space/edit/xyz) that would give me a editable
> >  representation of the above resource.
[...]
> I like it. Do you have corresponding URI spaces for delete, rename,
and other operations?


As interesting an approach as this may be, it is a Bad Idea [TM] to
reify HTTP / WebDAV methods, such as DELETE and MOVE, within resource
URIs. This fundamentally subverts the reason for having different HTTP
methods in the first place...

REST as realized by the Web is (thankfully) about more than GET and POST.


Regards,
Elias

On Fri, 04 Feb 2005 08:22:24 +1300, "Berend de Boer" <berend@...>
said:
> Just checked: removing the cookies empties your shopping cart...

OK, maybe I should have added the caveat "in principle"
to the statement that this is RESTful.

I didn't have time to fully reverse-engineer this
before posting it to rest-discuss, because my day
job has nothing to do with REST (or even computing).

I don't believe in a "cookies are bad" dogma, I just
believe that its useful to know the consequences of
using them from an architecture point of view.

For example, I think its pretty much impossible to do
useful authentication/authorisation and login/logout
functionality without cookies, because of useless
browser support for HTTP auth. But that doesn't mean
there aren't ways you can win by keeping the rest of
your app RESTful in its design.

Still, reading the code, I think the cookie is there so
the shopping cart can be repopulated after quitting the
browser, or a reload. Pretty orthogonal to maintaining
connection state. A *good* use of cookies, dare I say?

I'll probably study this properly over the weekend to
find out for sure, but I have a hard time seeing how
you couldn't POST a representation of the array of
ordered items.

Sandeep Shetty wrote:

>  This is similar to how I do it. Say you have a resource:
>  some-uri-space/sub-space/xyz I would have another resource
>  (some-uri-space/edit/xyz) that would give me a editable
>  representation of the above resource.

Interesting. Your edit form resources are not subordinates to the actual
resources you're editing.

This has the advantage that it makes it easy to exclude those resources
using /robots.txt.

>  Note that this resource exists only for browsers and GETting it
>  returns a From that is POSTed to some-uri-space/edit/xyz, which is
>  then interpreted as a PUT to some-uri-space/xyz on the server. I
>  achieve this by using some hidden Form fields that have a URI and a
>  method.

I like it. Do you have corresponding URI spaces for delete, rename, and
other operations?

-- Jason