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

REST way of logging out?

Expand Messages
  • sandeep@enterux.com
    Hey! Compliments of the season to everyone! :) I m new to the REST way of doing things and have a few questions to ask. Let me first put down some of my
    Message 1 of 5 , Dec 27, 2003
      Hey!

      Compliments of the season to everyone! :)

      I'm new to the REST way of doing things and have a few questions to ask.

      Let me first put down some of my assumptions of the RESTful way of doing things
      because if these assumptions themselves are wrong then just correcting them
      might provide me with the answers I need. :)

      - Uri's must be nouns for it to make sense for us to be able to GET them without
      having side effects.
      - In the context of browsers, since we don't have wide spread access to PUT and
      DELETE we use POST to accomplish them.


      Now, the questions:

      In a typical CMS application user are authenticated through sessions
      (application-state) with something like this:

      http://foo.com/user/login

      which would present the Login form (a Representation) which the user would fill
      up and POST to the same URI which would Login (an action that causes a
      change-in-state) the user. The change in state of the "user" resource is
      accomplished with a POST.

      Similarly,

      http://foo.com/page/edit/1
      http://foo.com/page/delete/1

      are representations of the "page with id 1" resource. Is this the right way to
      look at this??

      All changes in the state of that resource are accomplished with a <FORM
      action="POST"> for example, saving after you have edited the contents of "page
      with id 1" or committing a delete of "page with id 1".


      In most web application the logout action is accomplished through a URI which
      looks something like this:

      http://foo.com/user/logout

      This URI has the side effect of "logging out" the user and therefore it is
      inconsistent with my assumptions of REST.

      How can this be accomplished so that it makes sense in the current Web
      Applications scenario where users are used to logging out using a URI as
      opposed to a <FORM action="POST">?

      It seems that most of the so called webs scripting languages make it look like
      POST is just a non-transparent way of changing the state of a resource as
      opposed to the transparent GET. So developers tend to use the two
      interchangeably!

      Thanks! :)

      ----------------------------------------------------------------
    • Walden Mathews
      Sandeep, ... Yes, and two s complements of the season to you too! ... Uh oh! ... things ... them ... without ... Or just to make sense... ... PUT and ... When
      Message 2 of 5 , Dec 27, 2003
        Sandeep,

        : Hey!
        :
        : Compliments of the season to everyone! :)

        Yes, and two's complements of the season to you too!

        :
        : I'm new to the REST way of doing things and have a few questions to ask.

        Uh oh!

        :
        : Let me first put down some of my assumptions of the RESTful way of doing
        things
        : because if these assumptions themselves are wrong then just correcting
        them
        : might provide me with the answers I need. :)
        :
        : - Uri's must be nouns for it to make sense for us to be able to GET them
        without
        : having side effects.

        Or just to make sense...

        : - In the context of browsers, since we don't have wide spread access to
        PUT and
        : DELETE we use POST to accomplish them.

        When in Rome...

        :
        :
        : Now, the questions:
        :
        : In a typical CMS application user are authenticated through sessions
        : (application-state) with something like this:
        :
        : http://foo.com/user/login
        :
        : which would present the Login form (a Representation) which the user would
        fill
        : up and POST to the same URI which would Login (an action that causes a
        : change-in-state) the user. The change in state of the "user" resource is
        : accomplished with a POST.

        Sessions are probably better thought of as conversational state, not
        application state. But when hard pressed, the distinction could be hard
        to support. Anybody got a pat answer for this?

        --Walden


        :
        : Similarly,
        :
        : http://foo.com/page/edit/1
        : http://foo.com/page/delete/1
        :
        : are representations of the "page with id 1" resource. Is this the right
        way to
        : look at this??
        :
        : All changes in the state of that resource are accomplished with a <FORM
        : action="POST"> for example, saving after you have edited the contents of
        "page
        : with id 1" or committing a delete of "page with id 1".
        :
        :
        : In most web application the logout action is accomplished through a URI
        which
        : looks something like this:
        :
        : http://foo.com/user/logout
        :
        : This URI has the side effect of "logging out" the user and therefore it is
        : inconsistent with my assumptions of REST.
        :
        : How can this be accomplished so that it makes sense in the current Web
        : Applications scenario where users are used to logging out using a URI as
        : opposed to a <FORM action="POST">?
        :
        : It seems that most of the so called webs scripting languages make it look
        like
        : POST is just a non-transparent way of changing the state of a resource as
        : opposed to the transparent GET. So developers tend to use the two
        : interchangeably!
        :
        : Thanks! :)
        :
        : ----------------------------------------------------------------
        :
        :
        : To unsubscribe from this group, send an email to:
        : rest-discuss-unsubscribe@yahoogroups.com
        :
        :
        :
        : Yahoo! Groups Links
        :
        : To visit your group on the web, go to:
        : http://groups.yahoo.com/group/rest-discuss/
        :
        : 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/
        :
        :
        :
        : __________ NOD32 1.586 (20031226) Information __________
        :
        : This message was checked by NOD32 Antivirus System.
        : http://www.nod32.com
        :
        :
      • S. Alexander Jacobson
        ... My pat answer: Application state is the functionality you MUST provide no matter how much control you have over client functionality. Session state is
        Message 3 of 5 , Dec 28, 2003
          > Sessions are probably better thought of as conversational state, not
          > application state. But when hard pressed, the distinction could be hard
          > to support. Anybody got a pat answer for this?

          My pat answer: Application state is the
          functionality you MUST provide no matter how
          much control you have over client
          functionality. Session state is functionality
          that really belongs on the client, but that
          you can't put there fore logistical reasons.

          -Alex-

          ___________________________________________________________________
          S. Alexander Jacobson Check out my new blog!!!
          1-212-787-1914 voice http://alexjacobson.com
        • Walden Mathews
          I get you, Alex, but I wish you could word this so it doesn t sound like state = functionality. Can you? Also, how do you distinguish resource state from
          Message 4 of 5 , Dec 28, 2003
            I get you, Alex, but I wish you could word this
            so it doesn't sound like state = functionality. Can
            you?

            Also, how do you distinguish resource state from
            application state?

            Walden

            ----- Original Message -----
            From: "S. Alexander Jacobson" <alex@...>
            To: "Walden Mathews" <waldenm@...>
            Cc: <sandeep@...>; <rest-discuss@yahoogroups.com>
            Sent: Sunday, December 28, 2003 11:27 AM
            Subject: Re: [rest-discuss] REST way of logging out?


            : > Sessions are probably better thought of as conversational state, not
            : > application state. But when hard pressed, the distinction could be hard
            : > to support. Anybody got a pat answer for this?
            :
            : My pat answer: Application state is the
            : functionality you MUST provide no matter how
            : much control you have over client
            : functionality. Session state is functionality
            : that really belongs on the client, but that
            : you can't put there fore logistical reasons.
            :
            : -Alex-
            :
            : ___________________________________________________________________
            : S. Alexander Jacobson Check out my new blog!!!
            : 1-212-787-1914 voice http://alexjacobson.com
            :
            :
            : __________ NOD32 1.586 (20031226) Information __________
            :
            : This message was checked by NOD32 Antivirus System.
            : http://www.nod32.com
            :
            :
          • S. Alexander Jacobson
            ok, that was quick pat answer. trying again: Private resources are resources the state of which all users are indifferent/ignorant except one. Shared
            Message 5 of 5 , Dec 28, 2003
              ok, that was quick pat answer.
              trying again:

              Private resources are resources the state of
              which all users are indifferent/ignorant except
              one. Shared resources are all non-private
              resources. You host private resources on a shared
              server when the client isn't able to manipulate
              the private resource itself.

              -Alex-

              ___________________________________________________________________
              S. Alexander Jacobson Check out my new blog!!!
              1-212-787-1914 voice http://alexjacobson.com




              On Sun, 28 Dec 2003, Walden Mathews wrote:

              > I get you, Alex, but I wish you could word this
              > so it doesn't sound like state = functionality. Can
              > you?
              >
              > Also, how do you distinguish resource state from
              > application state?
              >
              > Walden
              >
              > ----- Original Message -----
              > From: "S. Alexander Jacobson" <alex@...>
              > To: "Walden Mathews" <waldenm@...>
              > Cc: <sandeep@...>; <rest-discuss@yahoogroups.com>
              > Sent: Sunday, December 28, 2003 11:27 AM
              > Subject: Re: [rest-discuss] REST way of logging out?
              >
              >
              > : > Sessions are probably better thought of as conversational state, not
              > : > application state. But when hard pressed, the distinction could be hard
              > : > to support. Anybody got a pat answer for this?
              > :
              > : My pat answer: Application state is the
              > : functionality you MUST provide no matter how
              > : much control you have over client
              > : functionality. Session state is functionality
              > : that really belongs on the client, but that
              > : you can't put there fore logistical reasons.
              > :
              > : -Alex-
              > :
              > : ___________________________________________________________________
              > : S. Alexander Jacobson Check out my new blog!!!
              > : 1-212-787-1914 voice http://alexjacobson.com
              > :
              > :
              > : __________ NOD32 1.586 (20031226) Information __________
              > :
              > : This message was checked by NOD32 Antivirus System.
              > : http://www.nod32.com
              > :
              > :
              >
            Your message has been successfully submitted and would be delivered to recipients shortly.