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
      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 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 2 of 29 , Feb 3, 2005
        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 3 of 29 , Feb 3, 2005
          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 4 of 29 , Feb 3, 2005
            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 5 of 29 , Feb 3, 2005
              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 6 of 29 , Feb 3, 2005
                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 7 of 29 , Feb 3, 2005
                  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 8 of 29 , Feb 3, 2005
                    > > > 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 9 of 29 , Feb 3, 2005
                      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 10 of 29 , Feb 3, 2005
                        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 11 of 29 , Feb 3, 2005
                          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.