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

request an email to be sent - what method?

Expand Messages
  • Robert Koberg
    Hi, What method should be used if the request is for an email to be sent? For example, you have a forgot password view. The user enters their email address,
    Message 1 of 11 , Feb 12, 2009
      Hi,

      What method should be used if the request is for an email to be sent?

      For example, you have a 'forgot password' view. The user enters their
      email address, submits the form and an email is sent with instructions
      on how to reset their password.

      It seems like this is a GET. Before REST, I would have probably used a
      POST.

      What method should it be?

      thanks,
      -Rob
    • Stan Dyck
      A GET needs to be safe and idempotent. If every time a dereference a URI it sends another email out to someone, it is neither safe nor idempotent so I say you
      Message 2 of 11 , Feb 12, 2009
        A GET needs to be safe and idempotent. If every time a dereference a URI it sends another email out to someone, it is
        neither safe nor idempotent so I say you should use POST.

        StanD.

        Robert Koberg wrote:
        >
        >
        > Hi,
        >
        > What method should be used if the request is for an email to be sent?
        >
        > For example, you have a 'forgot password' view. The user enters their
        > email address, submits the form and an email is sent with instructions
        > on how to reset their password.
        >
        > It seems like this is a GET. Before REST, I would have probably used a
        > POST.
        >
        > What method should it be?
        >
        > thanks,
        > -Rob
        >
      • Jon Hanna
        ... May I ask, why this seemed like a GET to you?
        Message 3 of 11 , Feb 12, 2009
          Robert Koberg wrote:
          > Hi,
          >
          > What method should be used if the request is for an email to be sent?
          >
          > For example, you have a 'forgot password' view. The user enters their
          > email address, submits the form and an email is sent with instructions
          > on how to reset their password.
          >
          > It seems like this is a GET. Before REST, I would have probably used a
          > POST.

          May I ask, why this seemed like a GET to you?
        • Robert Koberg
          ... (I keep forgetting to hit reply all) Because I am dense :) I understand now that sending the email is a side effect outside of the request/response cycle
          Message 4 of 11 , Feb 12, 2009
            On Feb 12, 2009, at 8:32 PM, Jon Hanna wrote:

            > Robert Koberg wrote:
            > > Hi,
            > >
            > > What method should be used if the request is for an email to be
            > sent?
            > >
            > > For example, you have a 'forgot password' view. The user enters
            > their
            > > email address, submits the form and an email is sent with
            > instructions
            > > on how to reset their password.
            > >
            > > It seems like this is a GET. Before REST, I would have probably
            > used a
            > > POST.
            >
            > May I ask, why this seemed like a GET to you?
            >

            (I keep forgetting to hit reply all)

            Because I am dense :) I understand now that sending the email is a
            side effect outside of the request/response cycle and so not safe.

            I was thinking that since the actual send of the email was not the
            responsibility the app server(s) that it is a safe and idempotent. It
            falls to the mail server to handle it so the app server can wash its
            hands of the situation.

            But, say a GET request is cached (on the originating server or at any
            hop along the way). Is that a side effect? If not, why not?

            -Rob
          • Robert Koberg
            I guess I am still confused. Is the distinction between the GET and POST in this instance that requested resource is viewed through a different client than the
            Message 5 of 11 , Feb 12, 2009
              I guess I am still confused. Is the distinction between the GET and
              POST in this instance that requested resource is viewed through a
              different client than the one requesting it? The user just clicks a
              button to get a view of a resource, but instead of returning to the
              browser the view is returned to an email client. Is that the
              distinction?

              I accept that it should be a POST, but, if side effects like caching
              and request logging are OK for GET, why not sending an email?

              Apologies for my newbie ignorance,
              -Rob


              On Feb 12, 2009, at 8:55 PM, Robert Koberg wrote:

              >
              > On Feb 12, 2009, at 8:32 PM, Jon Hanna wrote:
              >
              >> Robert Koberg wrote:
              >> > Hi,
              >> >
              >> > What method should be used if the request is for an email to be
              >> sent?
              >> >
              >> > For example, you have a 'forgot password' view. The user enters
              >> their
              >> > email address, submits the form and an email is sent with
              >> instructions
              >> > on how to reset their password.
              >> >
              >> > It seems like this is a GET. Before REST, I would have probably
              >> used a
              >> > POST.
              >>
              >> May I ask, why this seemed like a GET to you?
              >>
              >
              > (I keep forgetting to hit reply all)
              >
              > Because I am dense :) I understand now that sending the email is a
              > side effect outside of the request/response cycle and so not safe.
              >
              > I was thinking that since the actual send of the email was not the
              > responsibility the app server(s) that it is a safe and idempotent.
              > It falls to the mail server to handle it so the app server can wash
              > its hands of the situation.
              >
              > But, say a GET request is cached (on the originating server or at
              > any hop along the way). Is that a side effect? If not, why not?
              >
              > -Rob
            • mike amundsen
              check out this section of the spec for details on each method: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html the first sentence in each section should
              Message 6 of 11 , Feb 12, 2009
                check out this section of the spec for details on each method:
                http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

                the first sentence in each section should give you a clear idea of
                when each method should be used.

                mca
                http://amundsen.com/blog/




                On Thu, Feb 12, 2009 at 22:49, Robert Koberg <rob@...> wrote:
                > I guess I am still confused. Is the distinction between the GET and
                > POST in this instance that requested resource is viewed through a
                > different client than the one requesting it? The user just clicks a
                > button to get a view of a resource, but instead of returning to the
                > browser the view is returned to an email client. Is that the
                > distinction?
                >
                > I accept that it should be a POST, but, if side effects like caching
                > and request logging are OK for GET, why not sending an email?
                >
                > Apologies for my newbie ignorance,
                > -Rob
                >
                >
                > On Feb 12, 2009, at 8:55 PM, Robert Koberg wrote:
                >
                >>
                >> On Feb 12, 2009, at 8:32 PM, Jon Hanna wrote:
                >>
                >>> Robert Koberg wrote:
                >>> > Hi,
                >>> >
                >>> > What method should be used if the request is for an email to be
                >>> sent?
                >>> >
                >>> > For example, you have a 'forgot password' view. The user enters
                >>> their
                >>> > email address, submits the form and an email is sent with
                >>> instructions
                >>> > on how to reset their password.
                >>> >
                >>> > It seems like this is a GET. Before REST, I would have probably
                >>> used a
                >>> > POST.
                >>>
                >>> May I ask, why this seemed like a GET to you?
                >>>
                >>
                >> (I keep forgetting to hit reply all)
                >>
                >> Because I am dense :) I understand now that sending the email is a
                >> side effect outside of the request/response cycle and so not safe.
                >>
                >> I was thinking that since the actual send of the email was not the
                >> responsibility the app server(s) that it is a safe and idempotent.
                >> It falls to the mail server to handle it so the app server can wash
                >> its hands of the situation.
                >>
                >> But, say a GET request is cached (on the originating server or at
                >> any hop along the way). Is that a side effect? If not, why not?
                >>
                >> -Rob
                >
                >
                >
                > ------------------------------------
                >
                > Yahoo! Groups Links
                >
                >
                >
                >
              • Alan Dean
                Robert, Simply consider this: 1. Sending the email is an expected and intended behaviour. 2. Responses to GET are cacheable. 3. Cached responses mean that the
                Message 7 of 11 , Feb 12, 2009
                  Robert,

                  Simply consider this:

                  1. Sending the email is an expected and intended behaviour. 
                  2. Responses to GET are cacheable.
                  3. Cached responses mean that the request never reaches the orginating server.
                  4. Ergo, there will be apparently successful responses that do not exhibit the intended behaviour of sending an email.

                  Theoretically, POST responses are also cacheable and are therefore subject to the same problem.

                  On the other hand PUT requests are not cacheable and are therefore cannot be intermediated, which sounds like what you want in order to ensure emails are sent. A simple example might be (text/plain used for ease of reading):

                  -->
                  PUT /email/{unique-identifier}
                  Content-Type: text/plain


                  <--
                  201 Created

                  -->
                  GET /email/{unique-identifier}

                  <--
                  200 OK
                  Content-Type: text/plain
                  Expires: {Now +1 year}

                  This email was sent to john.doe@... at {date}.

                  Regards,
                  Alan Dean

                  On Fri, Feb 13, 2009 at 3:49 AM, Robert Koberg <rob@...> wrote:

                  I guess I am still confused. Is the distinction between the GET and
                  POST in this instance that requested resource is viewed through a
                  different client than the one requesting it? The user just clicks a
                  button to get a view of a resource, but instead of returning to the
                  browser the view is returned to an email client. Is that the
                  distinction?

                  I accept that it should be a POST, but, if side effects like caching
                  and request logging are OK for GET, why not sending an email?

                  Apologies for my newbie ignorance,
                  -Rob



                  On Feb 12, 2009, at 8:55 PM, Robert Koberg wrote:

                  >
                  > On Feb 12, 2009, at 8:32 PM, Jon Hanna wrote:
                  >
                  >> Robert Koberg wrote:
                  >> > Hi,
                  >> >
                  >> > What method should be used if the request is for an email to be
                  >> sent?
                  >> >
                  >> > For example, you have a 'forgot password' view. The user enters
                  >> their
                  >> > email address, submits the form and an email is sent with
                  >> instructions
                  >> > on how to reset their password.
                  >> >
                  >> > It seems like this is a GET. Before REST, I would have probably
                  >> used a
                  >> > POST.
                  >>
                  >> May I ask, why this seemed like a GET to you?
                  >>
                  >
                  > (I keep forgetting to hit reply all)
                  >
                  > Because I am dense :) I understand now that sending the email is a
                  > side effect outside of the request/response cycle and so not safe.
                  >
                  > I was thinking that since the actual send of the email was not the
                  > responsibility the app server(s) that it is a safe and idempotent.
                  > It falls to the mail server to handle it so the app server can wash
                  > its hands of the situation.
                  >
                  > But, say a GET request is cached (on the originating server or at
                  > any hop along the way). Is that a side effect? If not, why not?
                  >
                  > -Rob




                  --
                  Regards,
                  Alan Dean
                  Sent from: Woking Surrey United Kingdom.
                • Aristotle Pagaltzis
                  ... … … wiggy-wiggy-what!? Regards, -- Aristotle Pagaltzis //
                  Message 8 of 11 , Feb 13, 2009
                    * Alan Dean <alan.dean@...> [2009-02-13 07:45]:
                    > Theoretically, POST responses are also cacheable



                    … wiggy-wiggy-what!?

                    Regards,
                    --
                    Aristotle Pagaltzis // <http://plasmasturm.org/>
                  • Aristotle Pagaltzis
                    ... That’s not the right way to think about it. Pretty much every web server keeps an access log, and will make multiple entries in it if you make multiple
                    Message 9 of 11 , Feb 13, 2009
                      * Robert Koberg <rob@...> [2009-02-13 02:55]:
                      > Because I am dense :) I understand now that sending the email
                      > is a side effect outside of the request/response cycle and so
                      > not safe.
                      >
                      > I was thinking that since the actual send of the email was not
                      > the responsibility the app server(s) that it is a safe and
                      > idempotent. It falls to the mail server to handle it so the
                      > app server can wash its hands of the situation.
                      >
                      > But, say a GET request is cached (on the originating server or
                      > at any hop along the way). Is that a side effect? If not, why
                      > not?

                      That’s not the right way to think about it.

                      Pretty much every web server keeps an access log, and will make
                      multiple entries in it if you make multiple identical GET
                      requests. This is a side effect outside the req/resp cycle, but
                      that doesn’t make logging and GET requests antithetical.

                      The question is who assumes responsibility for the side effect.

                      GET requests are supposed to mean that the client is not asking
                      for any side effects whatsoever and cannot be held liable for any
                      such side effects that the server decides to perform.

                      In case of keeping log files, the server doesn’t even *want* the
                      client to be responsible, so keeping logs of GET accesses is
                      perfectly fine.

                      For an email being sent, OTOH, you want the client to bear full
                      responsibility, and that means you want anything but GET.

                      But if the server sent an email to the sysadmin every time
                      another 10,000 lines of access log records pile up, that would
                      fall under “safe” since the server takes responsibility, it does
                      not the expect the client to do so.

                      With that out of the way, we can get to the verbs: sending an
                      email on the client’s responsibility is certainly not an
                      idempotent side effect if it happens as many times as the request
                      is repeated. Therefore as a first approximation you want POST.

                      However, you could do something like mint a password request
                      token that can be used only once, in which case the password
                      request action becomes idempotent, and so you could then use PUT.

                      Regards,
                      --
                      Aristotle Pagaltzis // <http://plasmasturm.org/>
                    • Alan Dean
                      Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields. However, the 303 (See Other)
                      Message 10 of 11 , Feb 14, 2009
                        "Responses to this method are not cacheable, unless the response
                        includes appropriate Cache-Control or Expires header fields. However,
                        the 303 (See Other) response can be used to direct the user agent to
                        retrieve a cacheable resource." [1]

                        Typically, responses to POST are transient in nature and are not
                        crafted to be cached. However, they are 'theoretically' cacheable (see
                        above), whereas responses to PUT are specified as not cacheable.

                        [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5

                        Alan

                        On Sat, Feb 14, 2009 at 7:17 AM, Aristotle Pagaltzis <pagaltzis@...> wrote:
                        >
                        > * Alan Dean <alan.dean@...> [2009-02-13 07:45]:
                        >
                        > > Theoretically, POST responses are also cacheable
                        >
                        > …
                        >
                        > … wiggy-wiggy-what!?
                        >
                        > Regards,
                        > --
                        > Aristotle Pagaltzis // <http://plasmasturm.org/>
                      • Aristotle Pagaltzis
                        ... Right: the server is fully in control. So it makes no difference in whether you should choose PUT or POST. If you don’t want your responses to be cached,
                        Message 11 of 11 , Feb 14, 2009
                          * Alan Dean <alan.dean@...> [2009-02-14 11:00]:
                          > "Responses to this method are not cacheable, unless the
                          > response includes appropriate Cache-Control or Expires header
                          > fields. However, the 303 (See Other) response can be used to
                          > direct the user agent to retrieve a cacheable resource." [1]
                          >
                          > Typically, responses to POST are transient in nature and are
                          > not crafted to be cached. However, they are 'theoretically'
                          > cacheable (see above),

                          Right: the server is fully in control. So it makes no difference
                          in whether you should choose PUT or POST. If you don’t want your
                          responses to be cached, you don’t put in headers to declare it
                          cacheable. Done.

                          > whereas responses to PUT are specified as not cacheable.

                          I wonder why the RFC states that they are categorically
                          uncacheable. Seems to me that there wouldn’t have been any harm
                          in letting the origin server decide whether it wants to declare
                          the response cacheable or not.

                          Regards,
                          --
                          Aristotle Pagaltzis // <http://plasmasturm.org/>
                        Your message has been successfully submitted and would be delivered to recipients shortly.