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

RE: [rest-discuss] opinions need ed — multimedia algorithms the R EST way

Expand Messages
  • Markus KARG
    Why not inlining the image in a base64 encoded way? (didn t read the whole thread, maybe I missed the justification)
    Message 1 of 9 , Apr 12 12:43 PM
    • 0 Attachment
      Why not inlining the image in a base64 encoded way? (didn't read the whole thread, maybe I missed the justification)

      > -----Original Message-----
      > From: rest-discuss@yahoogroups.com [mailto:rest-
      > discuss@yahoogroups.com] On Behalf Of Marek Potociar
      > Sent: Dienstag, 12. April 2011 18:08
      > To: ruben.verborgh
      > Cc: rest-discuss@yahoogroups.com
      > Subject: Re: [rest-discuss] opinions needed — multimedia algorithms the
      > REST way
      >
      >
      >
      > On 04/08/2011 01:44 PM, ruben.verborgh wrote:
      > > We could first POST the image to http://other.org/images and then
      > access the face detection service by GETting
      > > http://other.org/images/34/faces.
      > > However, this involves two calls to other.org.
      >
      > This is a RESTful way to do it, assuming the post returns 201 with a
      > link to the .../34/faces (IMHO).
      >
      > Marek
      >
      >
      > ------------------------------------
      >
      > Yahoo! Groups Links
      >
      >
      >
    • mike amundsen
      I would use a representation body that supports a list of one or more files in either base64-encoded or a fully-qualified link to the file (HTML FORMS does
      Message 2 of 9 , Apr 12 1:19 PM
      • 0 Attachment
        I would use a representation body that supports a list of one or more
        files in either base64-encoded or a fully-qualified link to the file
        (HTML FORMS does this nicely).

        If you support both styles in a single state transfer then even
        clients that do not support base64-encoding (or cannot access local
        disk resources due to rights restrictions) will be able to supply the
        fully-qualified link.

        Then write a server that accepts the representation, processes the
        files (saves the base64 or navigates to the URI and saves that data),
        handles the recognition tasks and generates one or more new resources
        from the uploaded data.

        If the processing takes some time, the server can return 202 w/ a link
        the client can use to check on the progress of the server's work. If
        the processing is relatively quick, the server can return 201 with a
        location that points to the resulting resource created by the server
        (If more than one resource is created, I'd also create a single
        "top-level" resource that represents a set of links to all the other
        resources that were created by the client request).

        BTW - There is noting "REST-y" here; just basic HTTP stuff.

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


        #RESTFest 2010
        http://rest-fest.googlecode.com




        On Tue, Apr 12, 2011 at 15:43, Markus KARG <markus@...> wrote:
        > Why not inlining the image in a base64 encoded way? (didn't read the whole thread, maybe I missed the justification)
        >
        >> -----Original Message-----
        >> From: rest-discuss@yahoogroups.com [mailto:rest-
        >> discuss@yahoogroups.com] On Behalf Of Marek Potociar
        >> Sent: Dienstag, 12. April 2011 18:08
        >> To: ruben.verborgh
        >> Cc: rest-discuss@yahoogroups.com
        >> Subject: Re: [rest-discuss] opinions needed — multimedia algorithms the
        >> REST way
        >>
        >>
        >>
        >> On 04/08/2011 01:44 PM, ruben.verborgh wrote:
        >> > We could first POST the image to http://other.org/images and then
        >> access the face detection service by GETting
        >> > http://other.org/images/34/faces.
        >> > However, this involves two calls to other.org.
        >>
        >> This is a RESTful way to do it, assuming the post returns 201 with a
        >> link to the .../34/faces (IMHO).
        >>
        >> Marek
        >>
        >>
        >> ------------------------------------
        >>
        >> Yahoo! Groups Links
        >>
        >>
        >>
        >
        >
        >
        > ------------------------------------
        >
        > Yahoo! Groups Links
        >
        >
        >
        >
      • Ruben Verborgh
        Hi all, Thanks for the replies. This domain is very new to me, so I m eager to learn. The reason I would not use a base64-encoded body, is that I d lose the
        Message 3 of 9 , Apr 12 10:22 PM
        • 0 Attachment
          Hi all,

          Thanks for the replies. This domain is very new to me, so I'm eager to learn.

          The reason I would not use a base64-encoded body, is that I'd lose the resource oriented way of doing things.
          Or am I wrong here?

          I imagine such a request should go to http://example.com/facedetection, which is not really a resource. (Problem? Not a problem?)
          Or unless we see the algorithms themselves as resources, and go for http://example.com/algorithms/facedetection. No?

          I like the idea of 202, as some algorithms do indeed take some time.

          Ruben

          PS Why do you consider this not "REST-y" but basic HTTP stuff? I thought REST was about using basic HTTP to do things :)

          On 12 Apr 2011, at 22:19, mike amundsen wrote:

          > I would use a representation body that supports a list of one or more
          > files in either base64-encoded or a fully-qualified link to the file
          > (HTML FORMS does this nicely).
          >
          > If you support both styles in a single state transfer then even
          > clients that do not support base64-encoding (or cannot access local
          > disk resources due to rights restrictions) will be able to supply the
          > fully-qualified link.
          >
          > Then write a server that accepts the representation, processes the
          > files (saves the base64 or navigates to the URI and saves that data),
          > handles the recognition tasks and generates one or more new resources
          > from the uploaded data.
          >
          > If the processing takes some time, the server can return 202 w/ a link
          > the client can use to check on the progress of the server's work. If
          > the processing is relatively quick, the server can return 201 with a
          > location that points to the resulting resource created by the server
          > (If more than one resource is created, I'd also create a single
          > "top-level" resource that represents a set of links to all the other
          > resources that were created by the client request).
          >
          > BTW - There is noting "REST-y" here; just basic HTTP stuff.
          >
          > mca
          > http://amundsen.com/blog/
          > http://twitter.com@mamund
          > http://mamund.com/foaf.rdf#me
          >
          >
          > #RESTFest 2010
          > http://rest-fest.googlecode.com
          >
          >
          >
          >
          > On Tue, Apr 12, 2011 at 15:43, Markus KARG <markus@...> wrote:
          >> Why not inlining the image in a base64 encoded way? (didn't read the whole thread, maybe I missed the justification)
          >>
          >>> -----Original Message-----
          >>> From: rest-discuss@yahoogroups.com [mailto:rest-
          >>> discuss@yahoogroups.com] On Behalf Of Marek Potociar
          >>> Sent: Dienstag, 12. April 2011 18:08
          >>> To: ruben.verborgh
          >>> Cc: rest-discuss@yahoogroups.com
          >>> Subject: Re: [rest-discuss] opinions needed — multimedia algorithms the
          >>> REST way
          >>>
          >>>
          >>>
          >>> On 04/08/2011 01:44 PM, ruben.verborgh wrote:
          >>>> We could first POST the image to http://other.org/images and then
          >>> access the face detection service by GETting
          >>>> http://other.org/images/34/faces.
          >>>> However, this involves two calls to other.org.
          >>>
          >>> This is a RESTful way to do it, assuming the post returns 201 with a
          >>> link to the .../34/faces (IMHO).
          >>>
          >>> Marek
          >>>
          >>>
          >>> ------------------------------------
          >>>
          >>> Yahoo! Groups Links
          >>>
          >>>
          >>>
          >>
          >>
          >>
          >> ------------------------------------
          >>
          >> Yahoo! Groups Links
          >>
          >>
          >>
          >>
        • Marek Potociar
          ... ...using HTTP correctly is all about being REST-y :) After all, HTTP 1.1 was developed with REST architecture style in mind. Marek
          Message 4 of 9 , Apr 13 2:13 AM
          • 0 Attachment
            On 04/12/2011 10:19 PM, mike amundsen wrote:
            >
            > BTW - There is noting "REST-y" here; just basic HTTP stuff.

            ...using HTTP correctly is all about being REST-y :) After all, HTTP 1.1 was developed with REST architecture style in mind.

            Marek
          • mike amundsen
            Marek: ... There are lots of ways to use the HTTP transfer protocol correctly w/o adopting Fielding s REST architectural style; WebDAV is one
            Message 5 of 9 , Apr 13 5:42 AM
            • 0 Attachment
              Marek:

              <snip>
              >> BTW - There is noting "REST-y" here; just basic HTTP stuff.
              >
              > ...using HTTP correctly is all about being REST-y :) After all, HTTP 1.1 was developed with REST architecture style in mind.
              >
              </snip>

              There are lots of ways to use the HTTP transfer protocol correctly w/o
              adopting Fielding's REST architectural style; WebDAV is one
              standardized example.

              When the question is of the type "What's the best way to model this
              interaction...?" that does not _automatically_ rise to the level of a
              distributed network architectural issue.

              Granted we talk quite a bit on this list about the HTTP protocol;
              nothing bad there. However, it is important to keep in mind Fielding's
              style (like other architectural styles) is not only applicable to
              HTTP.

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


              #RESTFest 2010
              http://rest-fest.googlecode.com




              On Wed, Apr 13, 2011 at 05:13, Marek Potociar <marek.potociar@...> wrote:
              > On 04/12/2011 10:19 PM, mike amundsen wrote:
              >>
              >> BTW - There is noting "REST-y" here; just basic HTTP stuff.
              >
              > ...using HTTP correctly is all about being REST-y :) After all, HTTP 1.1 was developed with REST architecture style in mind.
              >
              > Marek
              >
            • Marek Potociar
              ... The original question was about the RESTful way of modeling the interaction using HTTP, not about the best way to model such interaction. For the latter we
              Message 6 of 9 , Apr 13 8:00 AM
              • 0 Attachment
                On 04/13/2011 02:42 PM, mike amundsen wrote:
                > When the question is of the type "What's the best way to model this
                > interaction...?" that does not _automatically_ rise to the level of a
                > distributed network architectural issue.


                The original question was about the RESTful way of modeling the interaction using HTTP, not about the best way to model
                such interaction. For the latter we don't have enough information anyway IMHO.

                > Granted we talk quite a bit on this list about the HTTP protocol;
                > nothing bad there. However, it is important to keep in mind Fielding's
                > style (like other architectural styles) is not only applicable to
                > HTTP.

                I cannot remember saying anything that would suggest that REST applies only to HTTP. I did say that HTTP 1.1 was
                designed with REST architecture style in mind, but that's a reverse implication. I certainly agree with you here.

                Marek
              • Markus KARG
                ... In part. It depends on your business domain definition. If the photo cannot live standalone (i. e. it is a real child to some outer resource, like the
                Message 7 of 9 , Apr 13 8:57 AM
                • 0 Attachment
                  > The reason I would not use a base64-encoded body, is that I'd lose the
                  > resource oriented way of doing things.
                  > Or am I wrong here?

                  In part. It depends on your business domain definition. If the photo cannot
                  live standalone (i. e. it is a "real" child to some outer resource, like the
                  photo on your driving licence cannot live without the licence card it is
                  glued upon), then you can safely transfer it as base64 within the resource.
                  But if have a lots of photos in a container and dynamically replace them
                  amongst containing resources, then you must use references (URIs) instead.
                  So, it is not about REST, but just about your business model. If you
                  virtually always would load the photo in a second step after loading the
                  driver's licence, the it is beneficial to prevent the additional GET and
                  just transfer the photo in the same resource, is it is just a part of that
                  resource and not a referenced "other thing".

                  Regards
                  Markus

                  >
                  > I imagine such a request should go to http://example.com/facedetection,
                  > which is not really a resource. (Problem? Not a problem?)
                  > Or unless we see the algorithms themselves as resources, and go for
                  > http://example.com/algorithms/facedetection. No?
                  >
                  > I like the idea of 202, as some algorithms do indeed take some time.
                  >
                  > Ruben
                  >
                  > PS Why do you consider this not "REST-y" but basic HTTP stuff? I
                  > thought REST was about using basic HTTP to do things :)
                  >
                  > On 12 Apr 2011, at 22:19, mike amundsen wrote:
                  >
                  > > I would use a representation body that supports a list of one or more
                  > > files in either base64-encoded or a fully-qualified link to the file
                  > > (HTML FORMS does this nicely).
                  > >
                  > > If you support both styles in a single state transfer then even
                  > > clients that do not support base64-encoding (or cannot access local
                  > > disk resources due to rights restrictions) will be able to supply the
                  > > fully-qualified link.
                  > >
                  > > Then write a server that accepts the representation, processes the
                  > > files (saves the base64 or navigates to the URI and saves that data),
                  > > handles the recognition tasks and generates one or more new resources
                  > > from the uploaded data.
                  > >
                  > > If the processing takes some time, the server can return 202 w/ a
                  > link
                  > > the client can use to check on the progress of the server's work. If
                  > > the processing is relatively quick, the server can return 201 with a
                  > > location that points to the resulting resource created by the server
                  > > (If more than one resource is created, I'd also create a single
                  > > "top-level" resource that represents a set of links to all the other
                  > > resources that were created by the client request).
                  > >
                  > > BTW - There is noting "REST-y" here; just basic HTTP stuff.
                  > >
                  > > mca
                  > > http://amundsen.com/blog/
                  > > http://twitter.com@mamund
                  > > http://mamund.com/foaf.rdf#me
                  > >
                  > >
                  > > #RESTFest 2010
                  > > http://rest-fest.googlecode.com
                  > >
                  > >
                  > >
                  > >
                  > > On Tue, Apr 12, 2011 at 15:43, Markus KARG <markus@...>
                  > wrote:
                  > >> Why not inlining the image in a base64 encoded way? (didn't read the
                  > whole thread, maybe I missed the justification)
                  > >>
                  > >>> -----Original Message-----
                  > >>> From: rest-discuss@yahoogroups.com [mailto:rest-
                  > >>> discuss@yahoogroups.com] On Behalf Of Marek Potociar
                  > >>> Sent: Dienstag, 12. April 2011 18:08
                  > >>> To: ruben.verborgh
                  > >>> Cc: rest-discuss@yahoogroups.com
                  > >>> Subject: Re: [rest-discuss] opinions needed - multimedia algorithms
                  > the
                  > >>> REST way
                  > >>>
                  > >>>
                  > >>>
                  > >>> On 04/08/2011 01:44 PM, ruben.verborgh wrote:
                  > >>>> We could first POST the image to http://other.org/images and then
                  > >>> access the face detection service by GETting
                  > >>>> http://other.org/images/34/faces.
                  > >>>> However, this involves two calls to other.org.
                  > >>>
                  > >>> This is a RESTful way to do it, assuming the post returns 201 with
                  > a
                  > >>> link to the .../34/faces (IMHO).
                  > >>>
                  > >>> Marek
                  > >>>
                  > >>>
                  > >>> ------------------------------------
                  > >>>
                  > >>> Yahoo! Groups Links
                  > >>>
                  > >>>
                  > >>>
                  > >>
                  > >>
                  > >>
                  > >> ------------------------------------
                  > >>
                  > >> Yahoo! Groups Links
                  > >>
                  > >>
                  > >>
                  > >>
                  >
                  >
                  >
                  > ------------------------------------
                  >
                  > Yahoo! Groups Links
                  >
                  >
                  >
                Your message has been successfully submitted and would be delivered to recipients shortly.