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

Re: [rest-discuss] Implementing MONITOR

Expand Messages
  • Jan Algermissen
    ... I d say: since every resource has state it makes sense to monitor its state. MONITOR simply means: POST a notification to the Reply-To URL if the state
    Message 1 of 13 , Dec 28, 2003
    • 0 Attachment
      Walden Mathews wrote:
      >
      > Jan,
      >
      > : > What are the arguments in favor of making MONITOR
      > : > a generic method, I wonder?
      > :
      > : The one that convinced my has been made by Mark: MONITOR uniform
      > : because it is meaningful to all resources, so it makes sense to have it.
      > : Besides: I learn only by doing and MONITOR is great for this ;-)
      >
      > I wonder what that means: "meaningful to all resources".

      I'd say: since every resource 'has state' it makes sense to monitor its
      state. MONITOR simply means: "POST a notification to the Reply-To URL
      if the state changes". I think of this notification as being a representation
      of the new state.

      > How would
      > you describe the state transition (or transfer) that occurs in response
      > to a MONITOR request?

      This is beyond my REST-knowledge I think. Is it necessary that this is
      doable? All I am sure of is that the response to MONITOR will be
      a "201 Created" with a Location header identifying the monitor.


      Maybe I don't understand.

      Hmm...all I want is to experiment and contribute some code that is
      easy to deploy. So far I can see some very interesting consequences of
      a MONITOR method, among them the possibility to turn servers into feeds
      and direct them all to a single 'consumer'-resource that can do all kinds
      of interesting combinations.

      >
      > : In the risk of asking something I should actually now, what does
      > : "incremental development" mean in the REST context?
      >
      > Nothing special for REST, just the idea of enhancing the
      > system in functional increments. But as I think about it more,
      > maybe me concern is really in the area of backward compatibility
      > with already implemented resources.

      But isn't a simple 405 (501?) enough to tell a client that
      MONITOR isn't implemented? This works fine with PUT and DELETE
      and the other HTTP/1.1 methods.
      >
      > I really need an aswer to my question above, or I don't know
      > what I'm talking about.

      Jan
      >
      > Walden
      >
      > 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/

      --
      Jan Algermissen http://www.topicmapping.com
      Consultant & Programmer http://www.gooseworks.org
    • Walden Mathews
      ... representation ... I m generally okay with that part. ... Depends on whether you re thinking or just tinking . This list is an architecture discussion
      Message 2 of 13 , Dec 28, 2003
      • 0 Attachment
        : > I wonder what that means: "meaningful to all resources".
        :
        : I'd say: since every resource 'has state' it makes sense to monitor its
        : state. MONITOR simply means: "POST a notification to the Reply-To URL
        : if the state changes". I think of this notification as being a
        representation
        : of the new state.

        I'm generally okay with that part.

        :
        : > How would
        : > you describe the state transition (or transfer) that occurs in response
        : > to a MONITOR request?
        :
        : This is beyond my REST-knowledge I think. Is it necessary that this is
        : doable? All I am sure of is that the response to MONITOR will be
        : a "201 Created" with a Location header identifying the monitor.

        Depends on whether you're "thinking" or just "tinking". This list is an
        architecture discussion list, so I would say yes, it is necessary.

        So I'll reiterate it: What resource state does MONITOR act on?

        Walden
      • Seth Johnson
        Is not the following the real issue here: The Reply-To URL would expect particular structures of representations of the monitored resource s state that the
        Message 3 of 13 , Dec 28, 2003
        • 0 Attachment
          Is not the following the real issue here:

          The Reply-To URL would expect particular structures of representations
          of the monitored resource's state that the monitored resource will
          POST to it. How do you make a MONITOR method that monitored resources
          would generically know how to handle, given this requirement?

          Much of REST is geared towards addressing the diversity of state
          structures that may arise.

          Seth Johnson


          -----Original Message-----
          From: Walden Mathews <waldenm@...>
          Date: Sun, 28 Dec 2003 17:37:50 -0500
          Subject: Re: [rest-discuss] Implementing MONITOR

          > : > I wonder what that means: "meaningful to all resources".
          > :
          > : I'd say: since every resource 'has state' it makes sense to monitor
          > : its state. MONITOR simply means: "POST a notification to the
          > : Reply-To URL if the state changes". I think of this notification
          > : as being a representation of the new state.
          >
          > I'm generally okay with that part.

          > : >
          > : > How would you describe the state transition (or transfer) that
          > : > occurs in response to a MONITOR request?
          > :
          > : This is beyond my REST-knowledge I think. Is it necessary that
          > : this is doable? All I am sure of is that the response to MONITOR
          > : will be a "201 Created" with a Location header identifying the
          > : monitor.
          >
          > Depends on whether you're "thinking" or just "tinking". This list is
          > an architecture discussion list, so I would say yes, it is necessary.
          >
          > So I'll reiterate it: What resource state does MONITOR act on?
        • Seth Johnson
          ... . . . or you d just say the monitored resource can send whatever representation it pleases (leaving aside content negotiation which might perhaps be part
          Message 4 of 13 , Dec 28, 2003
          • 0 Attachment
            > Is not the following the real issue here:
            >
            > The Reply-To URL would expect particular structures of
            > representations of the monitored resource's state that the monitored
            > resource will POST to it. How do you make a MONITOR method that
            > monitored resources would generically know how to handle, given this
            > requirement?
            >
            > Much of REST is geared towards addressing the diversity of state
            > structures that may arise.


            . . . or you'd just say the monitored resource can send whatever
            representation it pleases (leaving aside content negotiation which
            might perhaps be part of the original MONITOR request). But then why
            would it use POST to send the representation? (And how would it
            generically know what kind of POST structure is desired?)

            Seth Johnson
          • Jan Algermissen
            ... With an additional header that allows content negotiation to take place at the time of the MONITOR request. Propably Notify-Accept with the same
            Message 5 of 13 , Dec 29, 2003
            • 0 Attachment
              Seth Johnson wrote:
              >
              > Is not the following the real issue here:
              >
              > The Reply-To URL would expect particular structures of representations
              > of the monitored resource's state that the monitored resource will
              > POST to it. How do you make a MONITOR method that monitored resources
              > would generically know how to handle, given this requirement?

              With an additional header that allows content negotiation to take place
              at the time of the MONITOR request. Propably "Notify-Accept" with the
              same semantics as "Accept".

              Jan

              >
              > Much of REST is geared towards addressing the diversity of state
              > structures that may arise.
              >
              > Seth Johnson
              >
              > -----Original Message-----
              > From: Walden Mathews <waldenm@...>
              > Date: Sun, 28 Dec 2003 17:37:50 -0500
              > Subject: Re: [rest-discuss] Implementing MONITOR
              >
              > > : > I wonder what that means: "meaningful to all resources".
              > > :
              > > : I'd say: since every resource 'has state' it makes sense to monitor
              > > : its state. MONITOR simply means: "POST a notification to the
              > > : Reply-To URL if the state changes". I think of this notification
              > > : as being a representation of the new state.
              > >
              > > I'm generally okay with that part.
              >
              > > : >
              > > : > How would you describe the state transition (or transfer) that
              > > : > occurs in response to a MONITOR request?
              > > :
              > > : This is beyond my REST-knowledge I think. Is it necessary that
              > > : this is doable? All I am sure of is that the response to MONITOR
              > > : will be a "201 Created" with a Location header identifying the
              > > : monitor.
              > >
              > > Depends on whether you're "thinking" or just "tinking". This list is
              > > an architecture discussion list, so I would say yes, it is necessary.
              > >
              > > So I'll reiterate it: What resource state does MONITOR act on?
              >
              > 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/

              --
              Jan Algermissen http://www.topicmapping.com
              Consultant & Programmer http://www.gooseworks.org
            • Seth Johnson
              ... From: Jan Algermissen Date: Mon, 29 Dec 2003 10:30:55 +0100 Subject: Re: [rest-discuss] Implementing MONITOR ... So the
              Message 6 of 13 , Dec 29, 2003
              • 0 Attachment
                -----Original Message-----
                From: Jan Algermissen <jalgermissen@...>
                Date: Mon, 29 Dec 2003 10:30:55 +0100
                Subject: Re: [rest-discuss] Implementing MONITOR

                > Seth Johnson wrote:
                > >
                > > Is not the following the real issue here:
                > >
                > > The Reply-To URL would expect particular structures of
                > > representations of the monitored resource's state that the
                > > monitored resource will POST to it. How do you make a MONITOR
                > > method that monitored resources would generically know how to
                > > handle, given this requirement?
                >
                > With an additional header that allows content negotiation to take
                > place at the time of the MONITOR request. Propably "Notify-Accept"
                > with the same semantics as "Accept".


                So the monitored resource would have to only POST existing
                standard "content types?"

                Seth Johnson
              • Jan Algermissen
                ... Hmm...yes. what is the problem with this? Or in other words: why is this a problem in the case of MONITOR but not a problem for the other methods? Or am I
                Message 7 of 13 , Dec 29, 2003
                • 0 Attachment
                  Seth Johnson wrote:
                  >
                  > -----Original Message-----
                  > From: Jan Algermissen <jalgermissen@...>
                  > Date: Mon, 29 Dec 2003 10:30:55 +0100
                  > Subject: Re: [rest-discuss] Implementing MONITOR
                  >
                  > > Seth Johnson wrote:
                  > > >
                  > > > Is not the following the real issue here:
                  > > >
                  > > > The Reply-To URL would expect particular structures of
                  > > > representations of the monitored resource's state that the
                  > > > monitored resource will POST to it. How do you make a MONITOR
                  > > > method that monitored resources would generically know how to
                  > > > handle, given this requirement?
                  > >
                  > > With an additional header that allows content negotiation to take
                  > > place at the time of the MONITOR request. Propably "Notify-Accept"
                  > > with the same semantics as "Accept".
                  >
                  > So the monitored resource would have to only POST existing
                  > standard "content types?"

                  Hmm...yes. what is the problem with this? Or in other words: why
                  is this a problem in the case of MONITOR but not a problem for
                  the other methods?

                  Or am I misunderstanding your point?

                  Jan

                  >
                  > Seth Johnson

                  --
                  Jan Algermissen http://www.topicmapping.com
                  Consultant & Programmer http://www.gooseworks.org
                • Seth Johnson
                  ... Well, I think that POST is supposed to be much more flexible than that. But I m not sure it matters, after all. Seth Johnso -- DRM is Theft! We are the
                  Message 8 of 13 , Jan 2, 2004
                  • 0 Attachment
                    Jan Algermissen wrote:
                    >
                    > Seth Johnson wrote:
                    > >
                    > > -----Original Message-----
                    > > From: Jan Algermissen <jalgermissen@...>
                    > > Date: Mon, 29 Dec 2003 10:30:55 +0100
                    > > Subject: Re: [rest-discuss] Implementing MONITOR
                    > >
                    > > So the monitored resource would have to only POST existing
                    > > standard "content types?"
                    >
                    > Hmm...yes. what is the problem with this? Or in other words: why
                    > is this a problem in the case of MONITOR but not a problem for
                    > the other methods?
                    >
                    > Or am I misunderstanding your point?


                    Well, I think that POST is supposed to be much more flexible than that. But
                    I'm not sure it matters, after all.

                    Seth Johnso


                    --

                    DRM is Theft! We are the Stakeholders!

                    New Yorkers for Fair Use
                    http://www.nyfairuse.org

                    [CC] Counter-copyright: http://realmeasures.dyndns.org/cc

                    I reserve no rights restricting copying, modification or distribution of
                    this incidentally recorded communication. Original authorship should be
                    attributed reasonably, but only so far as such an expectation might hold for
                    usual practice in ordinary social discourse to which one holds no claim of
                    exclusive rights.
                  Your message has been successfully submitted and would be delivered to recipients shortly.