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

Re: [rest-discuss] Seeking feedback on the Blinksale API

Expand Messages
  • Roy T. Fielding
    ... Both. That is just a summary. The real constraint you are looking for is under 5.2.1: REST provides a hybrid of all three options by focusing on a shared
    Message 1 of 57 , Oct 2, 2006
      On Oct 2, 2006, at 8:37 AM, Mark Baker wrote:
      > On 10/1/06, Roy T. Fielding <fielding@...> wrote:
      > > Well, so do I. Self-descriptive means that the type is registered
      > and
      > > the registry points to a specification and the specification
      > explains
      > > how to process the data according to its intent.
      >
      > Ok, which one is it? 8-)
      >
      > "REST enables intermediate processing by constraining messages to be
      > self-descriptive: interaction is stateless between requests, standard
      > methods and media types are used to indicate semantics and exchange
      > information, and responses explicitly indicate cacheability."

      Both. That is just a summary. The real constraint you are looking
      for is under 5.2.1:

      REST provides a hybrid of all three options by focusing on a
      shared understanding of data types with metadata, but limiting
      the scope of what is revealed to a standardized interface.
      REST components communicate by transferring a representation of
      a resource in a format matching one of an evolving set of standard
      data types, selected dynamically based on the capabilities or
      desires of the recipient and the nature of the resource. Whether
      the representation is in the same format as the raw source, or is
      derived from the source, remains hidden behind the interface. ...

      This is one of those gray areas of increasing RESTfulness that will
      doubtless drive some people nuts. The problem is that I can't say
      "REST requires media types to be registered" because both Internet
      media types and the registry controlled by IANA are a specific
      architecture's instance of the style -- they could just as well be
      replaced by some other mechanism for metadata description.

      The broader question is what does it take to create an *evolving*
      set of standard data types? Obviously, I can't say that all data
      types have to be *the* standard before they are used in a REST-based
      architecture. At the same time, I do require enough standardization
      to allow the data format sent to be understood as such by the
      recipient. Hence, both sender and recipient agree to a common
      registration authority (the standard) for associating media types
      with data format descriptions. The degree to which the format chosen
      is a commonly accepted standard is less important than making sure
      that the sender and recipient agree to the same thing, and that's
      all I meant by an evolving set of standard data types.

      Sure, it is easier to deploy the use of a commonly understood data
      format. However, it is also more efficient to use a format
      that is more specifically intended for a given application.
      Where those two trade-offs intersect is often dependent on the
      application. REST does not demand that everyone agree on a single
      format for the exchange of data -- only that the participants in the
      communication agree. Beyond that, designers need to apply their
      own common sense and choose/create the best formats for the job.

      If we want to call one more RESTful than the other, then we have
      to take the goal of evolution into account. I would say it is more
      RESTful to use a specific standard type when applicable or to define
      a new type that is specific to a given purpose AND intended to be
      standardized for that application type (i.e., proprietary types are
      less RESTful than industry-wide standard types, but new standard
      types are not less RESTful than old standard types). But that is
      really only my personal preference, since the style does not
      constrain REST-based architectures to a single standard.

      ....Roy
    • Berend de Boer
      ... Scott I ve heard that you can t log out of a HTTP auth session, Scott but I think javascript could accomplish that for you. No JavaScript needed:
      Message 57 of 57 , Oct 10, 2006
        >>>>> "Scott" == Scott Chapman <scott_list@...> writes:

        Scott> I've heard that you can't "log out" of a HTTP auth session,
        Scott> but I think javascript could accomplish that for you.

        No JavaScript needed: http://www.pobox.com/~berend/rest/authentication.html

        --
        Regards,

        Berend. (-:
      Your message has been successfully submitted and would be delivered to recipients shortly.