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

getting a resource to be edited vs simply getting a resource

Expand Messages
  • david.nusbaum
    I searched but had a hard time isolating a similar topic... I m working a rest based application and am struggling with the challenge of when to return a
    Message 1 of 6 , Jan 16, 2007
      I searched but had a hard time isolating a similar topic...

      I'm working a rest based application and am struggling with the
      challenge of when to return a resource for edit (if a form) vs when to
      simply return the resource. I could always present the content in a
      form if the user is authorized, but this poses a couple of challenges:
      - additional overhead of populating selection lists when not needed
      - user may worry that than have changed something when that was not
      their intent.

      -Does somebody have experience that would suggest a different URI
      structure for when doing a GET to edit a resource?
      -Would it be appropriate to pass a parameter in this case, ie ?edit=yes

      Thanks,
    • Dr. Ernie Prabhakar
      Hi David, ... I don t know if this is the right answer, but that s the way that Rails 1.2 does it: http://topfunky.com/clients/peepcode/REST-cheatsheet.pdf
      Message 2 of 6 , Jan 16, 2007
        Hi David,

        > -Does somebody have experience that would suggest a different URI
        > structure for when doing a GET to edit a resource?
        > -Would it be appropriate to pass a parameter in this case, ie ?
        > edit=yes

        I don't know if this is the "right" answer, but that's the way that
        Rails 1.2 does it:

        http://topfunky.com/clients/peepcode/REST-cheatsheet.pdf

        Though they use ";edit" as the modifier, to distinguish from queries.

        -enp


        On Jan 16, 2007, at 11:41 AM, david.nusbaum wrote:

        > I searched but had a hard time isolating a similar topic...
        >
        > I'm working a rest based application and am struggling with the
        > challenge of when to return a resource for edit (if a form) vs when to
        > simply return the resource. I could always present the content in a
        > form if the user is authorized, but this poses a couple of challenges:
        > - additional overhead of populating selection lists when not needed
        > - user may worry that than have changed something when that was not
        > their intent.
        >
        > -Does somebody have experience that would suggest a different URI
        > structure for when doing a GET to edit a resource?
        > -Would it be appropriate to pass a parameter in this case, ie ?
        > edit=yes
        >
        > Thanks,
        >
        >
        >
      • Nic James Ferrier
        ... I struggled with this for a while with the app that I am working on. I choose to send the gui with any authorized request. I usually have an edit button
        Message 3 of 6 , Jan 16, 2007
          "david.nusbaum" <david.nusbaum@...> writes:

          > -Does somebody have experience that would suggest a different URI
          > structure for when doing a GET to edit a resource?
          > -Would it be appropriate to pass a parameter in this case, ie
          > ?edit=yes

          I struggled with this for a while with the app that I am working on.

          I choose to send the "gui" with any authorized request. I usually have
          an edit button that displays the gui.

          It works very well.

          Authenticated people are not such a caching concern anyway (because
          they're authenticated it's often the case that the content can't be
          cached). And it feels more natural to have a single resource
          controlling it's own destiny as it were.


          I'll be showing people my app this week so you'll be able to see this
          working, even if it's still a bit rough and ready.

          --
          Nic Ferrier
          http://www.tapsellferrier.co.uk for all your tapsell ferrier needs
        • Josh Sled
          ... You return representations, not resources. It might make it less confusing to realize that it is the view and edit representations that are separate,
          Message 4 of 6 , Jan 16, 2007
            On Tue, 2007-01-16 at 19:41 +0000, david.nusbaum wrote:
            > I'm working a rest based application and am struggling with the
            > challenge of when to return a resource for edit (if a form) vs when

            You return representations, not resources.

            It might make it less confusing to realize that it is the "view" and
            "edit" representations that are separate, not the resource.


            > -Does somebody have experience that would suggest a different URI
            > structure for when doing a GET to edit a resource?
            > -Would it be appropriate to pass a parameter in this case,
            > ie ?edit=yes

            Sure.

            - GET /wiki/foo
            - [click edit]
            - GET /wiki/foo?mode=edit
            (or /wiki/foo/editable, or /wiki/foo;edit, or...)
            - [make changes]
            - POST /wiki/foo

            Seems pretty webby and RESTful to me.

            --
            ...jsled
            http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo ${a}@${b}
          • Jon Hanna
            ... IMO it s perfectly acceptable to have a resource which allows one to edit another resource, and which therefore return representations to and from
            Message 5 of 6 , Jan 17, 2007
              Josh Sled wrote:
              > On Tue, 2007-01-16 at 19:41 +0000, david.nusbaum wrote:
              >> I'm working a rest based application and am struggling with the
              >> challenge of when to return a resource for edit (if a form) vs when
              >
              > You return representations, not resources.
              >
              > It might make it less confusing to realize that it is the "view" and
              > "edit" representations that are separate, not the resource.

              IMO it's perfectly acceptable to have a resource which allows one to
              edit another resource, and which therefore return representations to and
              from different URIs.
            • Benjamin Carlyle
              ... I would argue that the reason for having different representations available from a resource is to provide different levels of semantic fidelity based on
              Message 6 of 6 , Jan 20, 2007
                On Tue, 2007-01-16 at 17:07 -0500, Josh Sled wrote:
                > On Tue, 2007-01-16 at 19:41 +0000, david.nusbaum wrote:
                > > I'm working a rest based application and am struggling with the
                > > challenge of when to return a resource for edit (if a form) vs when
                > You return representations, not resources.
                > It might make it less confusing to realize that it is the "view" and
                > "edit" representations that are separate, not the resource.

                I would argue that the reason for having different representations
                available from a resource is to provide different levels of semantic
                fidelity based on client capabilities. Across these representations I
                would expect essentially the same information to be returned.

                Here, I think you are talking about one representation that returns
                resource content and another representation that returns a form to edit
                that content. Both representations would presumably be HTML, so they
                don't sound like representations of the same resource. They convey
                different information using the same content type. It sounds like they
                would require different urls. The two resources are related. It is
                likely the share state on the server. However, hyperlinking to one is a
                very different matter than hyperlinking to the other.

                You indicate as such here:
                > - GET /wiki/foo
                > - [click edit]
                > - GET /wiki/foo?mode=edit
                > (or /wiki/foo/editable, or /wiki/foo;edit, or...)
                > - [make changes]
                > - POST /wiki/foo

                An alternative design would be to include the edit form as part of the
                main representation, perhaps with its visible attribute set to false
                when javascript is available. A javascript toggle on the page might make
                the edit form visible and allow submission back to the server. This
                single response document design would only need one url.

                Benjamin.
              Your message has been successfully submitted and would be delivered to recipients shortly.