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

Re: [rest-discuss] Combining HTML and XML?

Expand Messages
  • Nathan
    ... Indeed, that s mainly because many have mentally positioned SPARQL on the server side making it un-RESTful, when you position it on the client side and GET
    Message 1 of 57 , Dec 29, 2010
    • 0 Attachment
      Eric J. Bowman wrote:
      > Welcome to the list, Benjamin.
      >
      >> "When representations are provided in hypertext form with typed
      >> relations (using microformats of HTML, RDF in N3 or XML, or even SVG),
      >> then automated agents can traverse these applications almost as well
      >> as any human. There are plenty of examples in the linked data
      >> communities. More important to me is that the same design reflects
      >> good human-Web design, and thus we can design the protocols to support
      >> both machine and human-driven applications by following the same
      >> architectural style."
      >>
      >
      > Roy's taking a shot at the RDF world, there, but it applies equally to
      > the matter at hand. Search for 'SPARQL +REST' and you'll come across a
      > couple of good papers explaining why SPARQL Protocol isn't REST (which
      > should be obvious to anyone who's read the thesis) and what can be done
      > about it.

      Indeed, that's mainly because many have mentally positioned SPARQL on
      the server side making it un-RESTful, when you position it on the client
      side and GET what you need + leverage HTTP cacheing, it's a whole
      different ball game.
    • Nathan
      ... Indeed, you often need the conflicting implementations in order to standardize, however I think the key conceptual difference Eric has been trying to get
      Message 57 of 57 , Jan 4, 2011
      • 0 Attachment
        Roy T. Fielding wrote:
        > On Jan 3, 2011, at 6:22 PM, Eric J. Bowman wrote:
        >> I still fail to see how both diametrically-opposed approaches can
        >> possibly be based on the same thesis. Roy's examples have never been
        >> based on the creation of custom data/media types. If REST were worded
        >> in a completely different way than it is, and Roy's examples always
        >> (instead of never) started with the creation of custom types, then I'd
        >> be wrong. But, REST and Roy are both quite clear that the style is NOT
        >> about creating custom media/data types, but is in fact the exact
        >> opposite of that approach.
        >
        > Do keep in mind that, in order to have an *evolving* set of standard
        > media types (and likewise standard link relations), there will have
        > to be new media types being created and old media types fading away
        > over time.
        >
        > One person's experiment may well become another person's standard,
        > in the long run, and REST is very much about the long run. So we
        > should consider new media types in terms of their long-term intent
        > rather than their immediate status.

        Indeed, you often need the conflicting implementations in order to
        standardize, however I think the key conceptual difference Eric has been
        trying to get across is summed up in your statement above, that we
        "should consider new media types in terms of their long-term intent",
        the distinction being that a media type being created with the long term
        in mind, with the principals like separation of concerns and
        web/internet-scale usage in mind, is RESTful (in the context of the
        web); whilst just dumping out an object from an application in XML,
        registering a +xml vnd type and creating a custom client, is not.

        Is that a fair comment / distinction to make?

        Best,

        Nathan
      Your message has been successfully submitted and would be delivered to recipients shortly.