ActiveResource Question

I was just browsing through the ActiveResource code and I wonder why
the use of .xml throughout on the URLs? Wouldn't it make more sense to
just have ActiveResource set the content type to application/xml and
then use paths without the extensions?

Sincerely,
Anthony Eden

I was just browsing through the ActiveResource code and I wonder why
the use of .xml throughout on the URLs? Wouldn't it make more sense to
just have ActiveResource set the content type to application/xml and
then use paths without the extensions?

In general, I think we're moving away from the idea of using the Accept
header as the primary way of determining the content type. The
extension makes a lot of things simpler. Including page caching,
scanning logs (you can easily tell HTML requests apart from XML ones),
and off-hand exploration (curl http://example.com/people.xml).

So given that direction, I want to make sure that Active Resource is
encouraging that behavior.

Anthony Eden wrote:

I was just browsing through the ActiveResource code and I wonder why
the use of .xml throughout on the URLs? Wouldn't it make more sense to
just have ActiveResource set the content type to application/xml and
then use paths without the extensions?

I believe it was David in his presentation "Discovering a World of
Resources on Rails", that made a good point about the use of extensions
that put any concerns I initially had to rest. It went something like,
xml is a good extension because it represents the actual content vs. an
extension like php, asp, etc. which represent which scripting language
was used on the server side.

It still seems wrong to me, since the resource is the same, just a
different representation of it, and thus it would seem that they
should be represented by the same URI.

If the decision has already been made then so be it, I can live with
it, but I still question it.

Sincerely,
Anthony Eden

It still seems wrong to me, since the resource is the same, just a
different representation of it, and thus it would seem that they
should be represented by the same URI.

We are indeed bending the notion of a resource. But I think the
trade-offs make it worth it.