Loading ...
Sorry, an error occurred while loading the content.

Re: [rest-discuss] Re: "Editable" Resources

Expand Messages
  • Jason Diamond
    ... These resources would *only* be used by crippled HTML browsers. Programmatic access by developers not using a browser could use the appropriate HTTP
    Message 1 of 29 , Feb 3, 2005
    • 0 Attachment
      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
    • Vincent D Murphy
      On Thu, 03 Feb 2005 12:46:46 -0800, Jason Diamond ... Well, URIs are cheap, so maybe you should distinguish between two URIs rather than two methods. This is
      Message 2 of 29 , Feb 3, 2005
      • 0 Attachment
        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.
      • Vincent D Murphy
        On Thu, 03 Feb 2005 22:13:56 +0100, Jan Algermissen ... I agree with your statement that the form is just another representation. I m not so sure that you
        Message 3 of 29 , Feb 3, 2005
        • 0 Attachment
          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
        • Vincent D Murphy
          On Thu, 03 Feb 2005 13:19:19 -0800, Jason Diamond ... Why not just do a PUT on the real resource whenever you receive a POST on the real resource? Having the
          Message 4 of 29 , Feb 3, 2005
          • 0 Attachment
            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.
          • Lucas Gonze
            ... 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
            Message 5 of 29 , Feb 3, 2005
            • 0 Attachment
              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.
            • Jason Diamond
              ... 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
              Message 6 of 29 , Feb 3, 2005
              • 0 Attachment
                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
              • Paul James
                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
                Message 7 of 29 , Feb 3, 2005
                • 0 Attachment
                  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/>.
                  >
                  >
                • Sandeep Shetty
                  ... 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
                  Message 8 of 29 , Feb 3, 2005
                  • 0 Attachment
                    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
                  • S. Mike Dierken
                    ... 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
                    Message 9 of 29 , Feb 3, 2005
                    • 0 Attachment
                      > > > 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'.
                    • Sandeep Shetty
                      ... 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
                      Message 10 of 29 , Feb 3, 2005
                      • 0 Attachment
                        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
                      • Sandeep Shetty
                        On Thu, 03 Feb 2005 22:13:56 +0100, Jan Algermissen ... This is exactly the same conclusion that I arrived at before I came up with the hack I mentioned in the
                        Message 11 of 29 , Feb 3, 2005
                        • 0 Attachment
                          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
                        • Sandeep Shetty
                          ... 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
                          Message 12 of 29 , Feb 3, 2005
                          • 0 Attachment
                            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
                          Your message has been successfully submitted and would be delivered to recipients shortly.