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

Submitting binary and metadata in a single request

Expand Messages
  • Jan Algermissen
    Hi, suppose I am writing a REST facade to a legacy system; one of the use cases being the creation of entries that consist of arbitrary media data and
    Message 1 of 10 , Jun 25, 2006
      Hi,

      suppose I am writing a REST facade to a legacy system; one of the use
      cases being the creation of entries that consist of arbitrary media
      data and asociated metadata. One approach to do this is to first POST
      the media data (and have the server return the created entry with the
      link to the uploaded media data) and then to update the metadata with
      a PUT on the entry.
      (That is the approach Atom is taking, at least in APP v08[1])

      What if the legacy system requires the creation and metadata
      assignment be done as an atomic operation, IOW if the entry cannot be
      created in the absence of the metadata?

      The only solution I see so far is a multipart form data upload but
      I'd really like to avoid having this clutter up my otherwise pretty
      consistent way of doing things in the system I have to build. E.g.
      I'd need to introduce te meaning of the form fields to the client
      where it otherwise would just POST the binary and then GET, modify
      and PUT the associated entry XML data.

      I have been thinking about a multipart POSTing of an entry XML
      document right away with the content link pointing to the multipart
      part that contains the binary data. I think the multipart specs does
      license that, yes?

      I'd really apprechiate any thoughts on this matter, thanks.

      Jan

      [1] http://www.ietf.org/internet-drafts/draft-ietf-atompub-
      protocol-08.txt
    • Berend de Boer
      ... Jan The only solution I see so far is a multipart form data Jan upload Agree. Jan but I d really like to avoid having this clutter up my Jan otherwise
      Message 2 of 10 , Jun 25, 2006
        >>>>> "Jan" == Jan Algermissen <jalgermissen@...> writes:

        Jan> The only solution I see so far is a multipart form data
        Jan> upload

        Agree.

        Jan> but I'd really like to avoid having this clutter up my
        Jan> otherwise pretty consistent way of doing things in the system
        Jan> I have to build. E.g. I'd need to introduce te meaning of
        Jan> the form fields to the client where it otherwise would just
        Jan> POST the binary and then GET, modify and PUT the associated
        Jan> entry XML data.

        Not sure if I understood this. But what about a GET, based on the
        guessed/determined media type which returns the applicable fields?

        Next you fill in the fields as in "then GET, modify and PUT the
        associated entry XML data."

        And you submit this together with the binary as a multipart form.

        I'm not sure why this is an issue for you. From the client it is just
        supplying values for fields. That the result is encoded as multipart
        form upload or send as a query string is a detail that the client can
        be blissfully unaware of IMO.

        --
        Regards,

        Berend. (-:
      • S. Mike Dierken
        ... There are other multipart approaches with MIME than multipart/form-data . The multipart/form-data results in an array of content blobs with headers like
        Message 3 of 10 , Jun 25, 2006
          > The only solution I see so far is a multipart form data upload but
          > I'd really like to avoid having this clutter up my otherwise pretty
          > consistent way of doing things in the system I have to build.
          There are other multipart approaches with MIME than 'multipart/form-data'.
          The 'multipart/form-data' results in an array of content blobs with headers
          like
          Content-Disposition: form-data; name="user"

          You might try POSTing the content and metadata using the 'multipart/mixed'
          or 'multipart/related' Content-Type. I haven't done the research to know
          whether they are appropriate, but it's a place to start.
        • Paul James
          Jan, How about thinking of the problem space as three related resources. One is your media data, one for your metadata, and one to represent your complete
          Message 4 of 10 , Jun 26, 2006
            Jan,

            How about thinking of the problem space as three related resources. One
            is your media data, one for your metadata, and one to represent your
            complete entry, tying the other two resources together. In that way the
            client can POST the data and metadata at leisure and then finalise the
            operation by creating the entry resource. The entry resource would just
            contain pointers (the URLs of) to the data and metadata. Would that be
            atomic enough for you?

            Paul.

            Jan Algermissen wrote:
            >
            > Hi,
            >
            > suppose I am writing a REST facade to a legacy system; one of the use
            > cases being the creation of entries that consist of arbitrary media
            > data and asociated metadata. One approach to do this is to first POST
            > the media data (and have the server return the created entry with the
            > link to the uploaded media data) and then to update the metadata with
            > a PUT on the entry.
            > (That is the approach Atom is taking, at least in APP v08[1])
            >
            > What if the legacy system requires the creation and metadata
            > assignment be done as an atomic operation, IOW if the entry cannot be
            > created in the absence of the metadata?
            >
            > The only solution I see so far is a multipart form data upload but
            > I'd really like to avoid having this clutter up my otherwise pretty
            > consistent way of doing things in the system I have to build. E.g.
            > I'd need to introduce te meaning of the form fields to the client
            > where it otherwise would just POST the binary and then GET, modify
            > and PUT the associated entry XML data.
            >
            > I have been thinking about a multipart POSTing of an entry XML
            > document right away with the content link pointing to the multipart
            > part that contains the binary data. I think the multipart specs does
            > license that, yes?
            >
            > I'd really apprechiate any thoughts on this matter, thanks.
            >
            > Jan
            >
            > [1] http://www.ietf.org/internet-drafts/draft-ietf-atompub-
            > <http://www.ietf.org/internet-drafts/draft-ietf-atompub->
            > protocol-08.txt
            >
            >
          • Chris Burdess
            ... As Mike says multipart/related is the way to go, see RFC 2387. If you are allergic to MIME multiparts for some reason, and depending on the complexity of
            Message 5 of 10 , Jun 26, 2006
              S. Mike Dierken wrote:
              >> The only solution I see so far is a multipart form data upload but
              >> I'd really like to avoid having this clutter up my otherwise pretty
              >> consistent way of doing things in the system I have to build.
              > There are other multipart approaches with MIME than 'multipart/form-
              > data'.
              > The 'multipart/form-data' results in an array of content blobs with
              > headers
              > like
              > Content-Disposition: form-data; name="user"
              >
              > You might try POSTing the content and metadata using the 'multipart/
              > mixed'
              > or 'multipart/related' Content-Type. I haven't done the research to
              > know
              > whether they are appropriate, but it's a place to start.

              As Mike says multipart/related is the way to go, see RFC 2387.

              If you are allergic to MIME multiparts for some reason, and depending
              on the complexity of your metadata another solution would be to use
              HTTP header extensions (X-* headers) for the metadata but these may
              not be preserved by non-transparent proxies so I don't think it's as
              clean a solution.
              --
              犬 Chris Burdess
              "They that can give up essential liberty to obtain a little safety
              deserve neither liberty nor safety." - Benjamin Franklin
            • Jan Algermissen
              Hi Chris, ... yes, that is what I thought. Thanks. From the RFC: The relationships among the body parts of a compound object distinguishes it from other
              Message 6 of 10 , Jun 26, 2006
                Hi Chris,

                > As Mike says multipart/related is the way to go, see RFC 2387.
                >

                yes, that is what I thought. Thanks.

                From the RFC:

                "The relationships among the body parts of a compound object
                distinguishes it from other object types. These relationships are
                often represented by links internal to the object's components that
                reference the other components. Within a single operating
                environment the links are often file names, such links may be
                represented within a MIME message using content-IDs or the value of
                some other "Content-" headers."

                The practical question arises, how does one reference from one body
                to the
                other (including the case where we might have more than one of these
                references).

                Here is an example (along Atom lines):

                Content-Type: Multipart/Related; boundary=myboundary
                type="application/xml"

                --myboundary
                Content-Type: application/xml
                Content-ID: 1
                <Entry>
                <Title>MyEntry</Title>
                <Content src="??"/>
                </Entry>
                --myboundary
                Content-Type: application/pdf
                Content-ID: 2

                T2xkIE1hY0RvbmFsZCBoYWQgYSBmYXJtCkUgSS
                BFIEkgTwpBbmQgb24gaGlzIGZhcm0gaGUgaGFk
                IHNvbWUgZHVja3MKRSBJIEUgSSBPCldpdGggYS
                BxdWFjayBxdWFjayBoZXJlLAphIHF1YWNrIHF1
                YWNrIHRoZXJlLApldmVyeSB3aGVyZSBhIHF1YW
                NrIHF1YWNrCkUgSSBFIEkgTwo=
                --myboundary--

                Any suggestions what to put into the src attribute to reference the
                second body part?
                Is there a URI scheme that covers that use case?

                Thanks.

                Jan



                > If you are allergic to MIME multiparts for some reason, and
                > depending on the complexity of your metadata another solution would
                > be to use HTTP header extensions (X-* headers) for the metadata but
                > these may not be preserved by non-transparent proxies so I don't
                > think it's as clean a solution.
                > --
                > 犬 Chris Burdess
                > "They that can give up essential liberty to obtain a little safety
                > deserve neither liberty nor safety." - Benjamin Franklin
                >
                >
                >
                >
              • Chris Burdess
                ... The cid: URL scheme covers exactly this circumstance, see RFC 2111. -- 犬 Chris Burdess They that can give up essential liberty to obtain a little safety
                Message 7 of 10 , Jun 26, 2006
                  Jan Algermissen wrote:
                  >> As Mike says multipart/related is the way to go, see RFC 2387.
                  >
                  > yes, that is what I thought. Thanks.
                  >
                  > From the RFC:
                  >
                  > "The relationships among the body parts of a compound object
                  > distinguishes it from other object types. These relationships are
                  > often represented by links internal to the object's components
                  > that
                  > reference the other components. Within a single operating
                  > environment the links are often file names, such links may be
                  > represented within a MIME message using content-IDs or the
                  > value of
                  > some other "Content-" headers."
                  >
                  > The practical question arises, how does one reference from one body
                  > to the
                  > other (including the case where we might have more than one of these
                  > references).
                  >
                  > Here is an example (along Atom lines):
                  >
                  > Content-Type: Multipart/Related; boundary=myboundary
                  > type="application/xml"
                  >
                  > --myboundary
                  > Content-Type: application/xml
                  > Content-ID: 1
                  > <Entry>
                  > <Title>MyEntry</Title>
                  > <Content src="??"/>
                  > </Entry>
                  > --myboundary
                  > Content-Type: application/pdf
                  > Content-ID: 2
                  >
                  > T2xkIE1hY0RvbmFsZCBoYWQgYSBmYXJtCkUgSS
                  > BFIEkgTwpBbmQgb24gaGlzIGZhcm0gaGUgaGFk
                  > IHNvbWUgZHVja3MKRSBJIEUgSSBPCldpdGggYS
                  > BxdWFjayBxdWFjayBoZXJlLAphIHF1YWNrIHF1
                  > YWNrIHRoZXJlLApldmVyeSB3aGVyZSBhIHF1YW
                  > NrIHF1YWNrCkUgSSBFIEkgTwo=
                  > --myboundary--
                  >
                  > Any suggestions what to put into the src attribute to reference the
                  > second body part?
                  > Is there a URI scheme that covers that use case?

                  The cid: URL scheme covers exactly this circumstance, see RFC 2111.
                  --
                  犬 Chris Burdess
                  "They that can give up essential liberty to obtain a little safety
                  deserve neither liberty nor safety." - Benjamin Franklin
                • Jan Algermissen
                  Chris, that is great, thanks. I would never have found that I guess. I d never expected that this use case has been covered and I could solve this sing
                  Message 8 of 10 , Jun 26, 2006
                    Chris,

                    that is great, thanks. I would never have found that I guess.

                    I'd never expected that this use case has been covered and I could solve
                    this sing standards. Amazing!

                    Jan


                    On Jun 26, 2006, at 4:10 PM, Chris Burdess wrote:

                    > Jan Algermissen wrote:
                    >>> As Mike says multipart/related is the way to go, see RFC 2387.
                    >>
                    >> yes, that is what I thought. Thanks.
                    >>
                    >> From the RFC:
                    >>
                    >> "The relationships among the body parts of a compound object
                    >> distinguishes it from other object types. These relationships
                    >> are
                    >> often represented by links internal to the object's components
                    >> that
                    >> reference the other components. Within a single operating
                    >> environment the links are often file names, such links may be
                    >> represented within a MIME message using content-IDs or the
                    >> value of
                    >> some other "Content-" headers."
                    >>
                    >> The practical question arises, how does one reference from one body
                    >> to the
                    >> other (including the case where we might have more than one of these
                    >> references).
                    >>
                    >> Here is an example (along Atom lines):
                    >>
                    >> Content-Type: Multipart/Related; boundary=myboundary
                    >> type="application/xml"
                    >>
                    >> --myboundary
                    >> Content-Type: application/xml
                    >> Content-ID: 1
                    >> <Entry>
                    >> <Title>MyEntry</Title>
                    >> <Content src="??"/>
                    >> </Entry>
                    >> --myboundary
                    >> Content-Type: application/pdf
                    >> Content-ID: 2
                    >>
                    >> T2xkIE1hY0RvbmFsZCBoYWQgYSBmYXJtCkUgSS
                    >> BFIEkgTwpBbmQgb24gaGlzIGZhcm0gaGUgaGFk
                    >> IHNvbWUgZHVja3MKRSBJIEUgSSBPCldpdGggYS
                    >> BxdWFjayBxdWFjayBoZXJlLAphIHF1YWNrIHF1
                    >> YWNrIHRoZXJlLApldmVyeSB3aGVyZSBhIHF1YW
                    >> NrIHF1YWNrCkUgSSBFIEkgTwo=
                    >> --myboundary--
                    >>
                    >> Any suggestions what to put into the src attribute to reference the
                    >> second body part?
                    >> Is there a URI scheme that covers that use case?
                    >
                    > The cid: URL scheme covers exactly this circumstance, see RFC 2111.
                    > --
                    > 犬 Chris Burdess
                    > "They that can give up essential liberty to obtain a little safety
                    > deserve neither liberty nor safety." - Benjamin Franklin
                    >
                    >
                    >
                    >
                  • S. Mike Dierken
                    Well, use cases tend to come from use, and the Internet has been in use for quite a while now. But you already knew that. (Let us know how this turns out,
                    Message 9 of 10 , Jun 26, 2006
                      Well, 'use cases' tend to come from use, and the Internet has been in use for quite a while now.

                      But you already knew that.

                      (Let us know how this turns out, sounds fun.)


                      > -----Original Message-----
                      > From: rest-discuss@yahoogroups.com
                      > [mailto:rest-discuss@yahoogroups.com] On Behalf Of Jan Algermissen
                      > Sent: Monday, June 26, 2006 7:17 AM
                      > To: Chris Burdess
                      > Cc: REST Discuss
                      > Subject: Re: [rest-discuss] Submitting binary and metadata in
                      > a single request
                      >
                      > Chris,
                      >
                      > that is great, thanks. I would never have found that I guess.
                      >
                      > I'd never expected that this use case has been covered and I
                      > could solve this sing standards. Amazing!
                      >
                      > Jan
                      >
                      >
                      > On Jun 26, 2006, at 4:10 PM, Chris Burdess wrote:
                      >
                      > > Jan Algermissen wrote:
                      > >>> As Mike says multipart/related is the way to go, see RFC 2387.
                      > >>
                      > >> yes, that is what I thought. Thanks.
                      > >>
                      > >> From the RFC:
                      > >>
                      > >> "The relationships among the body parts of a compound object
                      > >> distinguishes it from other object types. These relationships
                      > >> are
                      > >> often represented by links internal to the object's components
                      > >> that
                      > >> reference the other components. Within a single operating
                      > >> environment the links are often file names, such links may be
                      > >> represented within a MIME message using content-IDs or
                      > the value
                      > >> of
                      > >> some other "Content-" headers."
                      > >>
                      > >> The practical question arises, how does one reference from
                      > one body
                      > >> to the other (including the case where we might have more
                      > than one of
                      > >> these references).
                      > >>
                      > >> Here is an example (along Atom lines):
                      > >>
                      > >> Content-Type: Multipart/Related; boundary=myboundary
                      > >> type="application/xml"
                      > >>
                      > >> --myboundary
                      > >> Content-Type: application/xml
                      > >> Content-ID: 1
                      > >> <Entry>
                      > >> <Title>MyEntry</Title>
                      > >> <Content src="??"/>
                      > >> </Entry>
                      > >> --myboundary
                      > >> Content-Type: application/pdf
                      > >> Content-ID: 2
                      > >>
                      > >> T2xkIE1hY0RvbmFsZCBoYWQgYSBmYXJtCkUgSS
                      > >> BFIEkgTwpBbmQgb24gaGlzIGZhcm0gaGUgaGFk
                      > >> IHNvbWUgZHVja3MKRSBJIEUgSSBPCldpdGggYS
                      > >> BxdWFjayBxdWFjayBoZXJlLAphIHF1YWNrIHF1
                      > >> YWNrIHRoZXJlLApldmVyeSB3aGVyZSBhIHF1YW
                      > >> NrIHF1YWNrCkUgSSBFIEkgTwo=
                      > >> --myboundary--
                      > >>
                      > >> Any suggestions what to put into the src attribute to
                      > reference the
                      > >> second body part?
                      > >> Is there a URI scheme that covers that use case?
                      > >
                      > > The cid: URL scheme covers exactly this circumstance, see RFC 2111.
                      > > --
                      > > 犬 Chris Burdess
                      > > "They that can give up essential liberty to obtain a little safety
                      > > deserve neither liberty nor safety." - Benjamin Franklin
                      > >
                      > >
                      > >
                      > >
                      >
                      >
                      >
                      > ------------------------ Yahoo! Groups Sponsor
                      > --------------------~--> Something is new at Yahoo! Groups.
                      > Check out the enhanced email design.
                      > http://us.click.yahoo.com/SISQkA/gOaOAA/yQLSAA/W6uqlB/TM
                      > --------------------------------------------------------------
                      > ------~->
                      >
                      >
                      > Yahoo! Groups Links
                      >
                      >
                      >
                      >
                      >
                      >
                      >
                    • Bill de hÓra
                      ... Form multipart with cid URLs. I ve done this before. It ll work fine as long as the server can deconstruct the multipart correctly and your internal code
                      Message 10 of 10 , Jun 27, 2006
                        Jan Algermissen wrote:
                        >
                        >
                        > Hi,
                        >
                        > suppose I am writing a REST facade to a legacy system; one of the use
                        > cases being the creation of entries that consist of arbitrary media
                        > data and asociated metadata. One approach to do this is to first POST
                        > the media data (and have the server return the created entry with the
                        > link to the uploaded media data) and then to update the metadata with
                        > a PUT on the entry.
                        > (That is the approach Atom is taking, at least in APP v08[1])
                        >
                        > What if the legacy system requires the creation and metadata
                        > assignment be done as an atomic operation, IOW if the entry cannot be
                        > created in the absence of the metadata?

                        Form multipart with cid URLs. I've done this before. It'll work fine as
                        long as the server can deconstruct the multipart correctly and your
                        internal code can handle partially failures so that the client gets a
                        clean "all or nothing went" response. The latter is trickier if you're
                        going to send batches of meta+media in a single request.

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