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

Media-type for simple key/value store?

Expand Messages
  • Jorn Wildt
    A part of my current project is management of simple key/value properties (string/string) for (more or less) any resource in the system. My use-cases/scenarios
    Message 1 of 9 , Mar 21, 2012
      A part of my current project is management of simple key/value properties (string/string) for (more or less) any resource in the system.

      My use-cases/scenarios are:

      1) Some resource in the system contains a link with the rel-type "additional-properties". This link points to the list of additional properties for that resource (at the URL "{additional-properties}").

      2) The URL "{additional-properties}" returns a list of key/value properties for reading.

      3) For each key/value in the list there will be links for a) editing the value of the key, and 2) deleting the key.

      3a) Editing is as simple as PUTing a new value to the URL.

      3b) Deleting a key is as simple as a HTTP DELETE of the URL.

      4) The list also contains a link for adding new properties.

      What would be a suitable (simple) media-type for this?

      I am considering ATOM (which is nice for lists), but that seems like quite a bit of overkill. HTML might also be useful (but does not support PUT, but POST would be okay too). A home-grown application/vnd.abc+xml is also a possibility.

      What would you guys do?

      Thanks, Jørn
    • Robert Brewer
      ... Atom is for feeds, and HTML is for layout markup. You need something designed for transactional entities. Shoji [1] is a JSON-based protocol and media type
      Message 2 of 9 , Mar 21, 2012
        Jorn Wildt wrote:
        > A part of my current project is management of simple key/value
        > properties (string/string) for (more or less) any resource in the
        > system.
        >
        > My use-cases/scenarios are:
        >
        > 1) Some resource in the system contains a link with the rel-type
        > "additional-properties". This link points to the list of additional
        > properties for that resource (at the URL "{additional-properties}").
        >
        > 2) The URL "{additional-properties}" returns a list of key/value
        > properties for reading.
        >
        > 3) For each key/value in the list there will be links for a) editing
        > the value of the key, and 2) deleting the key.
        >
        > 3a) Editing is as simple as PUTing a new value to the URL.
        >
        > 3b) Deleting a key is as simple as a HTTP DELETE of the URL.
        >
        > 4) The list also contains a link for adding new properties.
        >
        > What would be a suitable (simple) media-type for this?
        >
        > I am considering ATOM (which is nice for lists), but that seems like
        > quite a bit of overkill. HTML might also be useful (but does not
        > support PUT, but POST would be okay too). A home-grown
        > application/vnd.abc+xml is also a possibility.

        Atom is for feeds, and HTML is for layout markup. You need something
        designed for transactional entities. Shoji [1] is a JSON-based protocol
        and media type designed for that, and it includes entity collections
        ("catalogs") as a bonus. Every Shoji Entity automatically includes the
        concept of using PUT to edit each attribute at its own URL (the server
        is free to return 405 for attributes where that method is not allowed).
        DELETE is specified for Entities, not Values as you describe above, but
        there's nothing stopping you from using DELETE that way.

        Shoji even covers the concept of "additional properties" for you;
        they're called "fragments" in Shoji.


        Robert Brewer
        fumanchu@...

        [1] http://www.aminus.org/rbre/shoji/shoji-draft-02.txt
      • mike amundsen
        a while back, i did an implementation of an idea that Roy posted to a list regarding managing properties of a resource. w/o his assent, i named this pattern
        Message 3 of 9 , Mar 21, 2012
          a while back, i did an implementation of an idea that Roy posted to a
          list regarding managing properties of a resource. w/o his assent, i
          named this pattern "Fielding Property Maps"[1]

          it's another possibility you might consider as it does not require a
          dedicated media type design to implement it cleanly. in fact, it could
          work in almost any media type design.

          this might be exactly what you need, but maybe it gives you some ideas.


          [1] http://www.amundsen.com/examples/fielding-props/

          mca
          http://amundsen.com/blog/
          http://twitter.com@mamund
          http://mamund.com/foaf.rdf#me




          On Wed, Mar 21, 2012 at 10:24, Jorn Wildt <jw@...> wrote:
          > A part of my current project is management of simple key/value properties (string/string) for (more or less) any resource in the system.
          >
          > My use-cases/scenarios are:
          >
          > 1) Some resource in the system contains a link with the rel-type "additional-properties". This link points to the list of additional properties for that resource (at the URL "{additional-properties}").
          >
          > 2) The URL "{additional-properties}" returns a list of key/value properties for reading.
          >
          > 3) For each key/value in the list there will be links for a) editing the value of the key, and 2) deleting the key.
          >
          > 3a) Editing is as simple as PUTing a new value to the URL.
          >
          > 3b) Deleting a key is as simple as a HTTP DELETE of the URL.
          >
          > 4) The list also contains a link for adding new properties.
          >
          > What would be a suitable (simple) media-type for this?
          >
          > I am considering ATOM (which is nice for lists), but that seems like quite a bit of overkill. HTML might also be useful (but does not support PUT, but POST would be okay too). A home-grown application/vnd.abc+xml is also a possibility.
          >
          > What would you guys do?
          >
          > Thanks, Jørn
          >
          >
          >
          > ------------------------------------
          >
          > Yahoo! Groups Links
          >
          >
          >
        • Jan Algermissen
          ... In any case, Roy s design (and Mike s specification around it) is a very educating use case - make sure you have a look. Besides that,
          Message 4 of 9 , Mar 21, 2012
            On Mar 21, 2012, at 3:56 PM, mike amundsen wrote:

            > a while back, i did an implementation of an idea that Roy posted to a
            > list regarding managing properties of a resource. w/o his assent, i
            > named this pattern "Fielding Property Maps"[1]
            >
            > it's another possibility you might consider as it does not require a
            > dedicated media type design to implement it cleanly. in fact, it could
            > work in almost any media type design.
            >
            > this might be exactly what you need, but maybe it gives you some ideas.
            >
            > [1] http://www.amundsen.com/examples/fielding-props/


            In any case, Roy's design (and Mike's 'specification' around it) is a very educating use case - make sure you have a look.

            Besides that, application/x-www-form-urlencoded is the way to go if you want a key/value format

            Jan






            >
            > mca
            > http://amundsen.com/blog/
            > http://twitter.com@mamund
            > http://mamund.com/foaf.rdf#me
            >
            > On Wed, Mar 21, 2012 at 10:24, Jorn Wildt <jw@...> wrote:
            > > A part of my current project is management of simple key/value properties (string/string) for (more or less) any resource in the system.
            > >
            > > My use-cases/scenarios are:
            > >
            > > 1) Some resource in the system contains a link with the rel-type "additional-properties". This link points to the list of additional properties for that resource (at the URL "{additional-properties}").
            > >
            > > 2) The URL "{additional-properties}" returns a list of key/value properties for reading.
            > >
            > > 3) For each key/value in the list there will be links for a) editing the value of the key, and 2) deleting the key.
            > >
            > > 3a) Editing is as simple as PUTing a new value to the URL.
            > >
            > > 3b) Deleting a key is as simple as a HTTP DELETE of the URL.
            > >
            > > 4) The list also contains a link for adding new properties.
            > >
            > > What would be a suitable (simple) media-type for this?
            > >
            > > I am considering ATOM (which is nice for lists), but that seems like quite a bit of overkill. HTML might also be useful (but does not support PUT, but POST would be okay too). A home-grown application/vnd.abc+xml is also a possibility.
            > >
            > > What would you guys do?
            > >
            > > Thanks, Jørn
            > >
            > >
            > >
            > > ------------------------------------
            > >
            > > Yahoo! Groups Links
            > >
            > >
            > >
            >
          • Tim Bray
            For a general-purpose key-value payload, I d use application/json. ... For a general-purpose key-value payload, I d use application/json. On Mar 21, 2012 4:24
            Message 5 of 9 , Mar 21, 2012

              For a general-purpose key-value payload, I'd use application/json.

              On Mar 21, 2012 4:24 AM, "Jorn Wildt" <jw@...> wrote:
              A part of my current project is management of simple key/value properties (string/string) for (more or less) any resource in the system.

              My use-cases/scenarios are:

              1) Some resource in the system contains a link with the rel-type "additional-properties". This link points to the list of additional properties for that resource (at the URL "{additional-properties}").

              2) The URL "{additional-properties}" returns a list of key/value properties for reading.

              3) For each key/value in the list there will be links for a) editing the value of the key, and 2) deleting the key.

              3a) Editing is as simple as PUTing a new value to the URL.

              3b) Deleting a key is as simple as a HTTP DELETE of the URL.

              4) The list also contains a link for adding new properties.

              What would be a suitable (simple) media-type for this?

              I am considering ATOM (which is nice for lists), but that seems like quite a bit of overkill. HTML might also be useful (but does not support PUT, but POST would be okay too). A home-grown application/vnd.abc+xml is also a possibility.

              What would you guys do?

              Thanks, Jørn



              ------------------------------------

              Yahoo! Groups Links

              <*> To visit your group on the web, go to:
                 http://groups.yahoo.com/group/rest-discuss/

              <*> Your email settings:
                 Individual Email | Traditional

              <*> To change settings online go to:
                 http://groups.yahoo.com/group/rest-discuss/join
                 (Yahoo! ID required)

              <*> To change settings via email:
                 rest-discuss-digest@yahoogroups.com
                 rest-discuss-fullfeatured@yahoogroups.com

              <*> 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/

            • Jorn Wildt
              Thanks for all the interesting inputs. I think I will go with the fielding properties approach - using x-www-form-urlencoded for the payload. At first I
              Message 6 of 9 , Mar 21, 2012
                Thanks for all the interesting inputs. I think I will go with the "fielding" properties approach - using x-www-form-urlencoded for the payload.

                At first I though Mike was suggesting the client should be hard coded to know that it could add ";props" to all URLs, which is not exactly in line with his work on hypermedia APIs ...

                Then I saw Fielding's comment: "Note that the entire URI prefix is determined by the origin server, so the properties might even be on a different server than the resource." and figured that the server has to supply the exact link. Much better :-)

                So, for now it becomes:

                1) Some resources in the system contains a link with the rel-type "additional-properties". This link points to the list of additional properties for that resource (at the URL "{additional-properties}").

                2) The URL "{additional-properties}" returns a list of key/value properties for reading. That "list" is represented with x-www-form-urlencoded.

                3) The whole set of properties for one resource can be updated by PUTing a set of values (using form-urlencoded again) to the "{additional-properties}" URL.

                4) The whole set of properties for one resource can be delete by DELETing the "{additional-properties}" URL.

                5) It is not possible to update a single key/value pair by itself. Neither is that required in out current use cases (which allows a user to edit the whole set of values at once).

                Thanks, Jørn
              • Sebastien Lambla
                Although I d highly recommend reminding yourself that multipart/form-data was created because of the shortcomings of form-urlencoded, such as not supporting
                Message 7 of 9 , Mar 23, 2012
                  Although I'd highly recommend reminding yourself that multipart/form-data was created because of the shortcomings of form-urlencoded, such as not supporting encodings properly, and browsers going against the spec on that one (and the spec being outdated).

                  Dragons ahead.

                  -----Original Message-----
                  From: rest-discuss@yahoogroups.com [mailto:rest-discuss@yahoogroups.com] On Behalf Of Jan Algermissen
                  Sent: 21 March 2012 20:11
                  To: mike amundsen
                  Cc: Jorn Wildt; rest-discuss@yahoogroups.com
                  Subject: Re: [rest-discuss] Media-type for simple key/value store?


                  On Mar 21, 2012, at 3:56 PM, mike amundsen wrote:

                  > a while back, i did an implementation of an idea that Roy posted to a
                  > list regarding managing properties of a resource. w/o his assent, i
                  > named this pattern "Fielding Property Maps"[1]
                  >
                  > it's another possibility you might consider as it does not require a
                  > dedicated media type design to implement it cleanly. in fact, it could
                  > work in almost any media type design.
                  >
                  > this might be exactly what you need, but maybe it gives you some ideas.
                  >
                  > [1] http://www.amundsen.com/examples/fielding-props/


                  In any case, Roy's design (and Mike's 'specification' around it) is a very educating use case - make sure you have a look.

                  Besides that, application/x-www-form-urlencoded is the way to go if you want a key/value format

                  Jan






                  >
                  > mca
                  > http://amundsen.com/blog/
                  > http://twitter.com@mamund
                  > http://mamund.com/foaf.rdf#me
                  >
                  > On Wed, Mar 21, 2012 at 10:24, Jorn Wildt <jw@...> wrote:
                  > > A part of my current project is management of simple key/value properties (string/string) for (more or less) any resource in the system.
                  > >
                  > > My use-cases/scenarios are:
                  > >
                  > > 1) Some resource in the system contains a link with the rel-type "additional-properties". This link points to the list of additional properties for that resource (at the URL "{additional-properties}").
                  > >
                  > > 2) The URL "{additional-properties}" returns a list of key/value properties for reading.
                  > >
                  > > 3) For each key/value in the list there will be links for a) editing the value of the key, and 2) deleting the key.
                  > >
                  > > 3a) Editing is as simple as PUTing a new value to the URL.
                  > >
                  > > 3b) Deleting a key is as simple as a HTTP DELETE of the URL.
                  > >
                  > > 4) The list also contains a link for adding new properties.
                  > >
                  > > What would be a suitable (simple) media-type for this?
                  > >
                  > > I am considering ATOM (which is nice for lists), but that seems like quite a bit of overkill. HTML might also be useful (but does not support PUT, but POST would be okay too). A home-grown application/vnd.abc+xml is also a possibility.
                  > >
                  > > What would you guys do?
                  > >
                  > > Thanks, Jørn
                  > >
                  > >
                  > >
                  > > ------------------------------------
                  > >
                  > > Yahoo! Groups Links
                  > >
                  > >
                  > >
                  >



                  ------------------------------------

                  Yahoo! Groups Links
                • Jorn Wildt
                  Good point Sebastien. You don t happen to know if specifying charset like below is valid (or simply widely accepted )? Content-Type:
                  Message 8 of 9 , Mar 26, 2012
                    Good point Sebastien.

                    You don't happen to know if specifying charset like below is valid (or simply "widely accepted")?

                    Content-Type: application/x-www-form-urlencoded;charset=UTF-8

                    /Jørn

                    --- In rest-discuss@yahoogroups.com, Sebastien Lambla <seb@...> wrote:
                    >
                    > Although I'd highly recommend reminding yourself that multipart/form-data was created because of the shortcomings of form-urlencoded, such as not supporting encodings properly, and browsers going against the spec on that one (and the spec being outdated).
                    >
                    > Dragons ahead.
                    >
                    > -----Original Message-----
                    > From: rest-discuss@yahoogroups.com [mailto:rest-discuss@yahoogroups.com] On Behalf Of Jan Algermissen
                    > Sent: 21 March 2012 20:11
                    > To: mike amundsen
                    > Cc: Jorn Wildt; rest-discuss@yahoogroups.com
                    > Subject: Re: [rest-discuss] Media-type for simple key/value store?
                    >
                    >
                    > On Mar 21, 2012, at 3:56 PM, mike amundsen wrote:
                    >
                    > > a while back, i did an implementation of an idea that Roy posted to a
                    > > list regarding managing properties of a resource. w/o his assent, i
                    > > named this pattern "Fielding Property Maps"[1]
                    > >
                    > > it's another possibility you might consider as it does not require a
                    > > dedicated media type design to implement it cleanly. in fact, it could
                    > > work in almost any media type design.
                    > >
                    > > this might be exactly what you need, but maybe it gives you some ideas.
                    > >
                    > > [1] http://www.amundsen.com/examples/fielding-props/
                    >
                    >
                    > In any case, Roy's design (and Mike's 'specification' around it) is a very educating use case - make sure you have a look.
                    >
                    > Besides that, application/x-www-form-urlencoded is the way to go if you want a key/value format
                    >
                    > Jan
                    >
                    >
                    >
                    >
                    >
                    >
                    > >
                    > > mca
                    > > http://amundsen.com/blog/
                    > > http://twitter.com@mamund
                    > > http://mamund.com/foaf.rdf#me
                    > >
                    > > On Wed, Mar 21, 2012 at 10:24, Jorn Wildt <jw@...> wrote:
                    > > > A part of my current project is management of simple key/value properties (string/string) for (more or less) any resource in the system.
                    > > >
                    > > > My use-cases/scenarios are:
                    > > >
                    > > > 1) Some resource in the system contains a link with the rel-type "additional-properties". This link points to the list of additional properties for that resource (at the URL "{additional-properties}").
                    > > >
                    > > > 2) The URL "{additional-properties}" returns a list of key/value properties for reading.
                    > > >
                    > > > 3) For each key/value in the list there will be links for a) editing the value of the key, and 2) deleting the key.
                    > > >
                    > > > 3a) Editing is as simple as PUTing a new value to the URL.
                    > > >
                    > > > 3b) Deleting a key is as simple as a HTTP DELETE of the URL.
                    > > >
                    > > > 4) The list also contains a link for adding new properties.
                    > > >
                    > > > What would be a suitable (simple) media-type for this?
                    > > >
                    > > > I am considering ATOM (which is nice for lists), but that seems like quite a bit of overkill. HTML might also be useful (but does not support PUT, but POST would be okay too). A home-grown application/vnd.abc+xml is also a possibility.
                    > > >
                    > > > What would you guys do?
                    > > >
                    > > > Thanks, Jørn
                    > > >
                    > > >
                    > > >
                    > > > ------------------------------------
                    > > >
                    > > > Yahoo! Groups Links
                    > > >
                    > > >
                    > > >
                    > >
                    >
                    >
                    >
                    > ------------------------------------
                    >
                    > Yahoo! Groups Links
                    >
                  • Sebastien Lambla
                    I need to look at the openrasta code. The lowdown is that I believe browsers send it in whatever charset format of the containing html page, without adding the
                    Message 9 of 9 , Mar 28, 2012
                      I need to look at the openrasta code. The lowdown is that I believe browsers send it in whatever charset format of the containing html page, without adding the charset and without using the default specified by the specification.

                      The rest of the issues are I believe summarized at the beginning of the spec on multipart/form-data.

                      Seb

                      ________________________________________
                      From: rest-discuss@yahoogroups.com [rest-discuss@yahoogroups.com] on behalf of Jorn Wildt [jw@...]
                      Sent: 26 March 2012 13:16
                      To: rest-discuss@yahoogroups.com
                      Subject: [rest-discuss] Re: Media-type for simple key/value store?

                      Good point Sebastien.

                      You don't happen to know if specifying charset like below is valid (or simply "widely accepted")?

                      Content-Type: application/x-www-form-urlencoded;charset=UTF-8

                      /Jørn

                      --- In rest-discuss@yahoogroups.com, Sebastien Lambla <seb@...> wrote:
                      >
                      > Although I'd highly recommend reminding yourself that multipart/form-data was created because of the shortcomings of form-urlencoded, such as not supporting encodings properly, and browsers going against the spec on that one (and the spec being outdated).
                      >
                      > Dragons ahead.
                      >
                      > -----Original Message-----
                      > From: rest-discuss@yahoogroups.com [mailto:rest-discuss@yahoogroups.com] On Behalf Of Jan Algermissen
                      > Sent: 21 March 2012 20:11
                      > To: mike amundsen
                      > Cc: Jorn Wildt; rest-discuss@yahoogroups.com
                      > Subject: Re: [rest-discuss] Media-type for simple key/value store?
                      >
                      >
                      > On Mar 21, 2012, at 3:56 PM, mike amundsen wrote:
                      >
                      > > a while back, i did an implementation of an idea that Roy posted to a
                      > > list regarding managing properties of a resource. w/o his assent, i
                      > > named this pattern "Fielding Property Maps"[1]
                      > >
                      > > it's another possibility you might consider as it does not require a
                      > > dedicated media type design to implement it cleanly. in fact, it could
                      > > work in almost any media type design.
                      > >
                      > > this might be exactly what you need, but maybe it gives you some ideas.
                      > >
                      > > [1] http://www.amundsen.com/examples/fielding-props/
                      >
                      >
                      > In any case, Roy's design (and Mike's 'specification' around it) is a very educating use case - make sure you have a look.
                      >
                      > Besides that, application/x-www-form-urlencoded is the way to go if you want a key/value format
                      >
                      > Jan
                      >
                      >
                      >
                      >
                      >
                      >
                      > >
                      > > mca
                      > > http://amundsen.com/blog/
                      > > http://twitter.com@mamund
                      > > http://mamund.com/foaf.rdf#me
                      > >
                      > > On Wed, Mar 21, 2012 at 10:24, Jorn Wildt <jw@...> wrote:
                      > > > A part of my current project is management of simple key/value properties (string/string) for (more or less) any resource in the system.
                      > > >
                      > > > My use-cases/scenarios are:
                      > > >
                      > > > 1) Some resource in the system contains a link with the rel-type "additional-properties". This link points to the list of additional properties for that resource (at the URL "{additional-properties}").
                      > > >
                      > > > 2) The URL "{additional-properties}" returns a list of key/value properties for reading.
                      > > >
                      > > > 3) For each key/value in the list there will be links for a) editing the value of the key, and 2) deleting the key.
                      > > >
                      > > > 3a) Editing is as simple as PUTing a new value to the URL.
                      > > >
                      > > > 3b) Deleting a key is as simple as a HTTP DELETE of the URL.
                      > > >
                      > > > 4) The list also contains a link for adding new properties.
                      > > >
                      > > > What would be a suitable (simple) media-type for this?
                      > > >
                      > > > I am considering ATOM (which is nice for lists), but that seems like quite a bit of overkill. HTML might also be useful (but does not support PUT, but POST would be okay too). A home-grown application/vnd.abc+xml is also a possibility.
                      > > >
                      > > > What would you guys do?
                      > > >
                      > > > Thanks, Jørn
                      > > >
                      > > >
                      > > >
                      > > > ------------------------------------
                      > > >
                      > > > Yahoo! Groups Links
                      > > >
                      > > >
                      > > >
                      > >
                      >
                      >
                      >
                      > ------------------------------------
                      >
                      > Yahoo! Groups Links
                      >




                      ------------------------------------

                      Yahoo! Groups Links
                    Your message has been successfully submitted and would be delivered to recipients shortly.