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

RESTifying

Expand Messages
  • mnotting
    I m trying to RESTify an existing Web application, and have a stylistic question. Imagine that a Web application fronts for a database, where all of the
    Message 1 of 14 , Jan 7, 2002
    • 0 Attachment
      I'm trying to RESTify an existing Web application, and have a
      stylistic question.

      Imagine that a Web application fronts for a database, where all of the
      records are available as resources.

      For example, you could search the database at
      http://www.example.org/search
      and the results would point at records, like
      http://www.example.org/records/theThing

      One can add to the database by doing a get (for the form) and then a
      POST to
      http://www.example.org/add

      Now, how should editing and deletion be done? One approach is to
      expose an edit resource, similar to the add one;
      http://www.example.org/edit
      To edit a specific resource, one could use a query string;
      http://www.example.org/edit?resource=theThing
      and use GET and POST to get the form and POST the edit.

      Another approach would be to use the resource's native URI, like
      http://www.example.org/records/theThing?mode=edit
      in a similar manner. This seems to be the approach taken by most
      WIKIs, interestingly.

      Is either approach preferable/horrible, or are they pretty much the
      same? The specific application is a gateway to an LDAP database. I
      haven't read Roy's full dissertation (still!), so apologies if I've
      asked a FAQ.

      Deletion is another interesting case; if each LDAP entry really is a
      resource, DELETE would be most appropriate, no? Unfortunately, methods
      other than GET and POST aren't available from HTML...

      Cheers,

      P.S.; Do queries identify a new resource? Their defined as a mechanism
      to pass data to the server. Common use (as outlined above) seems to
      indicate that people don't consider them separate, but in the URI
      world, they're not lumped into URI-References with fragments...
    • Mark Baker
      ... I have a thought about that that I ll bring up in another thread shortly. ... Why not POST to http://www.example.org/search? The good thing about doing
      Message 2 of 14 , Jan 7, 2002
      • 0 Attachment
        > I'm trying to RESTify an existing Web application, and have a
        > stylistic question.
        >
        > Imagine that a Web application fronts for a database, where all of the
        > records are available as resources.
        >
        > For example, you could search the database at
        > http://www.example.org/search
        > and the results would point at records, like
        > http://www.example.org/records/theThing

        I have a thought about that that I'll bring up in another thread
        shortly.

        > One can add to the database by doing a get (for the form) and then a
        > POST to
        > http://www.example.org/add

        Why not POST to http://www.example.org/search? The good thing about
        doing that is that an intermediary would know that /search has changed
        state due to the POST, whereas if it went to /add, the state change
        would be transparent and the intermediary wouldn't know. Also,
        /search may not be the best name if you're posting to it. What about
        this?

        http://www.example.org/database

        or, if the database is a list of employees;

        http://www.example.org/employees

        > Now, how should editing and deletion be done? One approach is to
        > expose an edit resource, similar to the add one;
        > http://www.example.org/edit
        > To edit a specific resource, one could use a query string;
        > http://www.example.org/edit?resource=theThing
        > and use GET and POST to get the form and POST the edit.
        >
        > Another approach would be to use the resource's native URI, like
        > http://www.example.org/records/theThing?mode=edit
        > in a similar manner. This seems to be the approach taken by most
        > WIKIs, interestingly.
        >
        > Is either approach preferable/horrible, or are they pretty much the
        > same? The specific application is a gateway to an LDAP database. I
        > haven't read Roy's full dissertation (still!), so apologies if I've
        > asked a FAQ.

        An "edit" should be done with a PUT interface, no? I know that this
        is problematic given that browsers/HTML only support GET/POST, but if
        you can afford it (development time, extra code to maintain, performance
        hit with another layer), I'd solve that problem after exposing the PUT
        interface, perhaps by having a separate Wiki-looking URI that accepts
        POSTs and treats them as PUTs.

        e.g.

        http://www.example.org/employees?id=234343?pap=true

        ("pap" => "post-as-put")

        > Deletion is another interesting case; if each LDAP entry really is a
        > resource, DELETE would be most appropriate, no? Unfortunately, methods
        > other than GET and POST aren't available from HTML...

        Yah. I'd do much the same as for PUT; build the DELETE interface, then
        kludge a POST interface on top.

        > P.S.; Do queries identify a new resource?

        Yes. Each unique URI identifies a new resource, modulo generic &
        per-scheme equivalence rules.

        > Their defined as a mechanism
        > to pass data to the server. Common use (as outlined above) seems to
        > indicate that people don't consider them separate, but in the URI
        > world, they're not lumped into URI-References with fragments...

        You can use them with URI refs;

        URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]
        absoluteURI = scheme ":" ( hier_part | opaque_part )
        relativeURI = ( net_path | abs_path | rel_path ) [ "?" query ]
        hier_part = ( net_path | abs_path ) [ "?" query ]

        More on this in that other email I promised.

        MB
        --
        Mark Baker, Chief Science Officer, Planetfred, Inc.
        Ottawa, Ontario, CANADA. mbaker@...
        http://www.markbaker.ca http://www.planetfred.com
      • Mark Nottingham
        ... hmm. Individual searches are separate resources; i.e., they have different query strings, so this wouldn t necessarily work, no? (It wouldn t make sense to
        Message 3 of 14 , Jan 7, 2002
        • 0 Attachment
          On Mon, Jan 07, 2002 at 10:03:17AM -0500, Mark Baker wrote:
          > > One can add to the database by doing a get (for the form) and then a
          > > POST to
          > > http://www.example.org/add
          >
          > Why not POST to http://www.example.org/search? The good thing about
          > doing that is that an intermediary would know that /search has changed
          > state due to the POST, whereas if it went to /add, the state change
          > would be transparent and the intermediary wouldn't know.

          hmm. Individual searches are separate resources; i.e., they have
          different query strings, so this wouldn't necessarily work, no? (It
          wouldn't make sense to POST a query, obviously).


          > Also, search may not be the best name if you're posting to it.
          > /What about
          > this?
          >
          > http://www.example.org/database
          >
          > or, if the database is a list of employees;
          >
          > http://www.example.org/employees

          Yes. I knew that that was a problem, just didn't have a good
          mechanism; perhaps it would be good to have a DN->resource mapping,
          so that

          http://www.example.org/addresses

          maps to 'dc=example,dc=org' (if that's the DN being used for
          addresses. Then, individual entries could be maped to

          http://www.example.org/addresses/Bob%20Smith

          or somesuch.

          This might be a horrible abuse of LDAP, but hey, I'd
          rather abuse it than the Web ;)


          > An "edit" should be done with a PUT interface, no? I know that this
          > is problematic given that browsers/HTML only support GET/POST, but if
          > you can afford it (development time, extra code to maintain, performance
          > hit with another layer), I'd solve that problem after exposing the PUT
          > interface, perhaps by having a separate Wiki-looking URI that accepts
          > POSTs and treats them as PUTs.
          >
          > e.g.
          >
          > http://www.example.org/employees?id=234343?pap=true
          >
          > ("pap" => "post-as-put")

          Sure. Perhaps start with pap and then backport. I'm doing this with
          python's BaseHTTPServer, so I can do anything fairly easily ;)


          > You can use them with URI refs;

          Yes. What I'm getting at is that the WIKI-like mechanisms such as

          http://www.example.com/theThing
          http://www.example.com/theThing?pap=true

          are a complete kludge; from a resource standpoint, these might as
          well be

          http://www.example.com/theThing
          http:/www.example.com/someOtherThing

          because of opacity; the only person who knows that ?pap=true does
          something special is the publisher.

          P.S. it would be interesting to see an analysis of the RESTyness of
          WIKIs.


          --
          Mark Nottingham
          http://www.mnot.net/
        • Mark Baker
          ... Why not? Don t think of the resource as being a search, but think of it as the result of a search. http://www.google.com/search?q=foo is the set of all
          Message 4 of 14 , Jan 7, 2002
          • 0 Attachment
            > > Why not POST to http://www.example.org/search? The good thing about
            > > doing that is that an intermediary would know that /search has changed
            > > state due to the POST, whereas if it went to /add, the state change
            > > would be transparent and the intermediary wouldn't know.
            >
            > hmm. Individual searches are separate resources; i.e., they have
            > different query strings, so this wouldn't necessarily work, no? (It
            > wouldn't make sense to POST a query, obviously).

            Why not? Don't think of the resource as being a search, but think of
            it as the result of a search.

            "http://www.google.com/search?q=foo" is the set of all resources known
            by Google to contain the word "foo". That it requires a search to
            resolve this URI at google.com is immaterial really.

            So there's no problem with POSTing to /search. That would be one way
            for Google to allow people to register new unindexed resources, for
            example. But as mentioned below, the name is confusing.

            > > Also, search may not be the best name if you're posting to it.
            > > /What about
            > > this?
            > >
            > > http://www.example.org/database
            > >
            > > or, if the database is a list of employees;
            > >
            > > http://www.example.org/employees
            >
            > Yes. I knew that that was a problem, just didn't have a good
            > mechanism; perhaps it would be good to have a DN->resource mapping,
            > so that
            >
            > http://www.example.org/addresses
            >
            > maps to 'dc=example,dc=org' (if that's the DN being used for
            > addresses. Then, individual entries could be maped to
            >
            > http://www.example.org/addresses/Bob%20Smith
            >
            > or somesuch.
            >
            > This might be a horrible abuse of LDAP, but hey, I'd
            > rather abuse it than the Web ;)

            Heh. But do you understand what I was saying here, after what I just
            wrote above?

            > > http://www.example.org/employees?id=234343?pap=true
            > >
            > > ("pap" => "post-as-put")
            >
            > Sure. Perhaps start with pap and then backport. I'm doing this with
            > python's BaseHTTPServer, so I can do anything fairly easily ;)

            Anything except implement a catchall do_* method (I'm writing a
            proxy). 8-)

            > > You can use them with URI refs;
            >
            > Yes. What I'm getting at is that the WIKI-like mechanisms such as
            >
            > http://www.example.com/theThing
            > http://www.example.com/theThing?pap=true
            >
            > are a complete kludge; from a resource standpoint, these might as
            > well be
            >
            > http://www.example.com/theThing
            > http:/www.example.com/someOtherThing
            >
            > because of opacity; the only person who knows that ?pap=true does
            > something special is the publisher.

            Exactly right. An alternative is to tunnel PUT and DELETE through
            POST with a hidden form field called "method". At least the URI
            wouldn't change. I guess there's a number of ways to kludge it.
            That would make for a good RESTwiki page.

            > P.S. it would be interesting to see an analysis of the RESTyness of
            > WIKIs.

            This one has been up on the RESTwiki for a while. It's pretty
            good, I think.

            http://internet.conveyor.com/RESTwiki/moin.cgi/HowWikiComparesToRest

            MB
            --
            Mark Baker, Chief Science Officer, Planetfred, Inc.
            Ottawa, Ontario, CANADA. mbaker@...
            http://www.markbaker.ca http://www.planetfred.com
          • Mark Nottingham
            ... Well, there s no problem POSTing an update to /search (or whatever), but doing a query through POST doesn t seem very RESTy at all. So, to review (and make
            Message 5 of 14 , Jan 7, 2002
            • 0 Attachment
              On Mon, Jan 07, 2002 at 01:45:52PM -0500, Mark Baker wrote:
              > > > Why not POST to http://www.example.org/search? The good thing about
              > > > doing that is that an intermediary would know that /search has changed
              > > > state due to the POST, whereas if it went to /add, the state change
              > > > would be transparent and the intermediary wouldn't know.
              > >
              > > hmm. Individual searches are separate resources; i.e., they have
              > > different query strings, so this wouldn't necessarily work, no? (It
              > > wouldn't make sense to POST a query, obviously).
              >
              > Why not? Don't think of the resource as being a search, but think of
              > it as the result of a search.
              >
              > "http://www.google.com/search?q=foo" is the set of all resources known
              > by Google to contain the word "foo". That it requires a search to
              > resolve this URI at google.com is immaterial really.
              >
              > So there's no problem with POSTing to /search. That would be one way
              > for Google to allow people to register new unindexed resources, for
              > example. But as mentioned below, the name is confusing.

              Well, there's no problem POSTing an update to /search (or whatever),
              but doing a query through POST doesn't seem very RESTy at all.

              So, to review (and make sure I've got a cohesive interface),

              http://www.example.org/addresses
              Exposes the DB as a whole
              GET: representation is the main interface (queries, etc.)
              POST: add a new entry, returns a 303 to the created resource
              http://www.example.org/addresses?repr=add
              GET: representation is an add form
              http://www.example.org/addresses?query_to_the_db
              GET: representation is a listing of the query
              http://www.example.org/addresses/thePerson
              exposes a particular record
              GET: representation is a person's record
              POST: update the resource/record, returns a 303 to the resource
              PUT: create the resource/record (multiple content-types
              supported?), returns a status page (or a 303?)
              DELETE: delete the resource/record, returns a status page
              http://www.example.org/addresses/thePerson?repr=edit
              GET: representation is an edit form

              These duplicate functionality above:

              http://www.example.org/addresses/thePerson?method=PUT
              POST: tunnels to PUT, returns a status page
              http://www.example.org/addresses/thePerson?method=DELETE
              POST: tunnels to DELETE, returns a status page


              I'm a *little* uncomfortable with the ?repr=add, but I can't say
              exactly why.


              > Exactly right. An alternative is to tunnel PUT and DELETE through
              > POST with a hidden form field called "method". At least the URI
              > wouldn't change. I guess there's a number of ways to kludge it.
              > That would make for a good RESTwiki page.

              That would be cool. I like the method= kludge...


              > http://internet.conveyor.com/RESTwiki/moin.cgi/HowWikiComparesToRest

              Ah, I'd seen that, but never investigated. Thanks.


              --
              Mark Nottingham
              http://www.mnot.net/
            • Mark Nottingham
              ... Hmm. Seems good; will have to play. ... [...] ... What s the media type for an HTML form which is the editable representation of a resource again? ;) Also,
              Message 6 of 14 , Jan 7, 2002
              • 0 Attachment
                On Mon, Jan 07, 2002 at 08:42:42PM -0500, Mark Baker wrote:
                > > http://www.example.org/addresses
                > > Exposes the DB as a whole
                > > GET: representation is the main interface (queries, etc.)
                > > POST: add a new entry, returns a 303 to the created resource
                >
                > Hmm, if you're creating a new resource it should be returned with a
                > 201. You won't get an auto redirect, but the client will know the
                > URI of the new resource. The body can also include a link if a
                > browser is your client.

                Hmm. Seems good; will have to play.


                > > http://www.example.org/addresses?repr=add
                > > GET: representation is an add form
                >
                > /addresses could serve that purposes, no need for the new URI.
                > Content negotiation could be used to negotiate a representation
                > capable of expressing a form.
                [...]
                > > http://www.example.org/addresses/thePerson?repr=edit
                > > GET: representation is an edit form
                >
                > Again, could content negotiation not be used to retrieve an editable
                > format?

                What's the media type for an HTML form which is the editable
                representation of a resource again? ;)

                Also, how would I tell a browser to request it?


                > BTW, my other message I promised is turning into something that should
                > probably be sent to uri@..., so stay tuned.

                Cool!

                --
                Mark Nottingham
                http://www.mnot.net/
              • Mark Baker
                ... Right. I guess I wasn t clear, my apologies. ... Hmm, if you re creating a new resource it should be returned with a 201. You won t get an auto redirect,
                Message 7 of 14 , Jan 7, 2002
                • 0 Attachment
                  > > So there's no problem with POSTing to /search. That would be one way
                  > > for Google to allow people to register new unindexed resources, for
                  > > example. But as mentioned below, the name is confusing.
                  >
                  > Well, there's no problem POSTing an update to /search (or whatever),
                  > but doing a query through POST doesn't seem very RESTy at all.

                  Right. I guess I wasn't clear, my apologies.

                  > So, to review (and make sure I've got a cohesive interface),
                  >
                  > http://www.example.org/addresses
                  > Exposes the DB as a whole
                  > GET: representation is the main interface (queries, etc.)
                  > POST: add a new entry, returns a 303 to the created resource

                  Hmm, if you're creating a new resource it should be returned with a
                  201. You won't get an auto redirect, but the client will know the
                  URI of the new resource. The body can also include a link if a
                  browser is your client.

                  > http://www.example.org/addresses?repr=add
                  > GET: representation is an add form

                  /addresses could serve that purposes, no need for the new URI.
                  Content negotiation could be used to negotiate a representation
                  capable of expressing a form.

                  > http://www.example.org/addresses?query_to_the_db
                  > GET: representation is a listing of the query

                  Looks good.

                  > http://www.example.org/addresses/thePerson
                  > exposes a particular record
                  > GET: representation is a person's record
                  > POST: update the resource/record, returns a 303 to the resource
                  > PUT: create the resource/record (multiple content-types
                  > supported?), returns a status page (or a 303?)
                  > DELETE: delete the resource/record, returns a status page

                  Good.

                  > http://www.example.org/addresses/thePerson?repr=edit
                  > GET: representation is an edit form

                  Again, could content negotiation not be used to retrieve an editable
                  format?

                  BTW, my other message I promised is turning into something that should
                  probably be sent to uri@..., so stay tuned.

                  MB
                  --
                  Mark Baker, Chief Science Officer, Planetfred, Inc.
                  Ottawa, Ontario, CANADA. mbaker@...
                  http://www.markbaker.ca http://www.planetfred.com
                • Mark Nottingham
                  ... I was hoping to allow requests to the record resource http://www.example.com/addresses/thePerson to negotiate the representation returned, so that the
                  Message 8 of 14 , Jan 7, 2002
                  • 0 Attachment
                    On Mon, Jan 07, 2002 at 08:42:42PM -0500, Mark Baker wrote:
                    > Content negotiation could be used to negotiate a representation
                    > capable of expressing a form.

                    I was hoping to allow requests to the record resource
                    http://www.example.com/addresses/thePerson
                    to negotiate the representation returned, so that the default would
                    be to return an HTML page, but if linked from an <img> element, the
                    image/jpeg in the jpegPhoto attribute would be returned.

                    Sadly, it's not to be. Conneg support in browsers is horrible.
                    Mozilla sends a static Accept header, no matter what the context,
                    which enumerates all of the types it supports. I've logged a bug[1]
                    for this (please vote for it if so inclined).

                    IE seems to generate the Accept header based on the filename
                    extension of the resource (EW!), and by default sends a header that
                    includes a lot of image/ types, a */* (which is a CUAP[2]), but no
                    HTML.

                    Of course, conneg is still useful to expose, but lack of support in
                    browsers means that another means of doing this -- probably with
                    query strings (or maybe path parameters?) -- will have to be hacked.

                    *sigh*


                    [1] http://bugzilla.mozilla.org/show_bug.cgi?bug_id=118696
                    [2] http://www.w3.org/TR/cuap


                    Hmm... Bugzilla would be an excellent candidate for RESTification...


                    --
                    Mark Nottingham
                    http://www.mnot.net/
                  • Mark Nottingham
                    ... Oops, that should be [1] http://bugzilla.mozilla.org/show_bug.cgi?id=118696 -- Mark Nottingham http://www.mnot.net/
                    Message 9 of 14 , Jan 7, 2002
                    • 0 Attachment
                      On Mon, Jan 07, 2002 at 10:51:03PM -0800, Mark Nottingham wrote:
                      > [1] http://bugzilla.mozilla.org/show_bug.cgi?bug_id=118696

                      Oops, that should be
                      [1] http://bugzilla.mozilla.org/show_bug.cgi?id=118696


                      --
                      Mark Nottingham
                      http://www.mnot.net/
                    • mdierken
                      ... I ve used the ?method= approach for a couple years (actually used do:method for collision avoidance) to tunnel methods. I ve also used ? accept= to tunnel
                      Message 10 of 14 , Jan 16, 2002
                      • 0 Attachment
                        >
                        > Of course, conneg is still useful to expose, but lack of support in
                        > browsers means that another means of doing this -- probably with
                        > query strings (or maybe path parameters?) -- will have to be hacked.
                        >
                        > *sigh*

                        I've used the ?method= approach for a couple years (actually used
                        do:method for collision avoidance) to tunnel methods. I've also used ?
                        accept= to tunnel Accept headers.

                        Why not use the LDAP dn in the URL?
                        For example, I wrote a servlet a while back to do stuff like this:

                        http://www.xmldatasource.com:7779/xds/ldap2xml/

                        http://www.xmldatasource.com:7779/xds/ldap2xml/db.debian.org/ou=users/
                        uid=myxie/

                        http://www.xmldatasource.com:7779/xds/ldap2xml/db.debian.org/ou=users/
                        uid=myxie/?do:accept=text/xml

                        Mike
                      • mdierken
                        ... Even if you tunnel Accept header in the URL (which means you need to control the server or have a generic intermediary that un-tunnels them) you ll want to
                        Message 11 of 14 , Jan 16, 2002
                        • 0 Attachment
                          --- In rest-discuss@y..., Mark Nottingham <mnot@m...> wrote:
                          >
                          > On Mon, Jan 07, 2002 at 08:42:42PM -0500, Mark Baker wrote:
                          > > Content negotiation could be used to negotiate a representation
                          > > capable of expressing a form.
                          >
                          > I was hoping to allow requests to the record resource
                          > http://www.example.com/addresses/thePerson
                          > to negotiate the representation returned, so that the default would
                          > be to return an HTML page, but if linked from an <img> element, the
                          > image/jpeg in the jpegPhoto attribute would be returned.
                          >

                          Even if you tunnel Accept header in the URL (which means you need to
                          control the server or have a generic intermediary that un-tunnels
                          them) you'll want to consider strongly using sub-resource for images
                          and stuff.
                          If the URI space you design can address LDAP attributes, then you'd
                          have the problem solved maybe?
                        • Mark Nottingham
                          So, I m inclined to make the jpg a subresource (along with other attributes), but this leaves me with a bit of a headache; how do I identify an HTML-editable
                          Message 12 of 14 , Jan 16, 2002
                          • 0 Attachment
                            So, I'm inclined to make the jpg a subresource (along with other
                            attributes), but this leaves me with a bit of a headache; how do I
                            identify an HTML-editable version of the resource? If I make it
                            another subresource, e.g.,
                            .../thePerson/editform
                            there's the (theoretical) possibility of a namespace clash. So, I can
                            either define sub-sub-resources
                            .../thePerson/attr/jpegPhoto
                            .../thePerson/other/editform
                            which is icky, or I can use a query arg or attribute;
                            .../thePerson?repr=editform --or--
                            .../thePerson;editform

                            In combination with the method and conneg hacks, then, I could have
                            .../thePerson?repr=editform&method=PUT&accept=text/xml
                            (not really applicable to this representation, but you get the idea)

                            I think I like using a parameter best; is there any semantic
                            difference worth noting (from a REST standpoint) between query args
                            and parameters?

                            Regarding putting the DN in the URI; I was concerned about
                            typability, etc., until it occured to me earlier today that I could
                            have a "typeable" interface optimised for people hand-typing URIs,
                            jsut as there's a search interface optimised for HTML form
                            submission; e.g.,
                            http://addresses.example.org/name/Mark+Nottingham
                            or somesuch.



                            On Wed, Jan 16, 2002 at 08:01:03AM -0000, mdierken wrote:
                            >
                            > >
                            > > Of course, conneg is still useful to expose, but lack of support in
                            > > browsers means that another means of doing this -- probably with
                            > > query strings (or maybe path parameters?) -- will have to be hacked.
                            > >
                            > > *sigh*
                            >
                            > I've used the ?method= approach for a couple years (actually used
                            > do:method for collision avoidance) to tunnel methods. I've also used ?
                            > accept= to tunnel Accept headers.
                            >
                            > Why not use the LDAP dn in the URL?
                            > For example, I wrote a servlet a while back to do stuff like this:
                            >
                            > http://www.xmldatasource.com:7779/xds/ldap2xml/
                            >
                            > http://www.xmldatasource.com:7779/xds/ldap2xml/db.debian.org/ou=users/
                            > uid=myxie/
                            >
                            > http://www.xmldatasource.com:7779/xds/ldap2xml/db.debian.org/ou=users/
                            > uid=myxie/?do:accept=text/xml
                            >
                            > Mike
                            >
                            >
                            >
                            > To unsubscribe from this group, send an email to:
                            > rest-discuss-unsubscribe@yahoogroups.com
                            >
                            >
                            >
                            > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                            >
                            >

                            --
                            Mark Nottingham
                            http://www.mnot.net/
                          • mdierken
                            ... Not sure if I understand method=PUT and accept together. PUT would have a content-type though. Identifying the editable representation is a bother. Once I
                            Message 13 of 14 , Jan 17, 2002
                            • 0 Attachment
                              --- In rest-discuss@y..., Mark Nottingham <mnot@m...> wrote:
                              >
                              > In combination with the method and conneg hacks, then, I could have
                              > .../thePerson?repr=editform&method=PUT&accept=text/xml
                              > (not really applicable to this representation, but you get the idea)

                              Not sure if I understand method=PUT and accept together.
                              PUT would have a content-type though.

                              Identifying the editable representation is a bother.
                              Once I tried uri?method=edit but didn't like that, so ditched it
                              before anybody noticed.
                              Tried uri?layout=editor - moving in the right direction. Kept that
                              for a while.

                              Don't know what to try next. Maybe uri?view=editor - 'view' is a
                              wonderfully ambigous noun/verb.

                              Mike
                            • mdierken
                              ... Another reason to use view is when accessing a heirchical collection of information or a database-like thing it can be fun to talk about slices or
                              Message 14 of 14 , Jan 17, 2002
                              • 0 Attachment
                                --- In rest-discuss@y..., "mdierken" <mdierken@y...> wrote:
                                > --- In rest-discuss@y..., Mark Nottingham <mnot@m...> wrote:

                                > Identifying the editable representation is a bother.
                                > Once I tried uri?method=edit but didn't like that, so ditched it
                                > before anybody noticed.
                                > Tried uri?layout=editor - moving in the right direction. Kept that
                                > for a while.
                                >
                                > Don't know what to try next. Maybe uri?view=editor - 'view' is a
                                > wonderfully ambigous noun/verb.
                                >

                                Another reason to use 'view' is when accessing a heirchical
                                collection of information or a database-like thing it can be fun to
                                talk about 'slices' or 'views' thorough a multi-dimensional space.

                                Although it might not make as much sense when I wake up tomorrow...
                              Your message has been successfully submitted and would be delivered to recipients shortly.