Re: [rest-discuss] Combining HTML and XML?
- Eric J. Bowman wrote:
> Welcome to the list, Benjamin.Indeed, that's mainly because many have mentally positioned SPARQL on
>> "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.
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.
- Roy T. Fielding wrote:
> On Jan 3, 2011, at 6:22 PM, Eric J. Bowman wrote:Indeed, you often need the conflicting implementations in order to
>> 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.
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?