[uf-rest] Fwd: [microformats-discuss] REX! Re: REST-discuss list,
Dr. Ernie Prabhakar
drernie at opendarwin.org
Mon Oct 31 16:34:11 PST 2005
Just a quick reply to this post:
On Oct 25, 2005, at 9:26 PM, Dr. Ernie Prabhakar wrote:
> Yeah, I have concerns too if this is the proposal.
To be precise, this is "a" proposal. Others are welcome, and
probably needed. However, this is intended to be the *simplest*
possible encoding, to use as a starting point.
> The biggest problem is that HTML over HTTP is already RESTful.
> Every web page with a form is already a self-descriptive hypertext
> document on how to compose
> the request.
Sure, but not all HTML is a web service. Certainly not all HTML can
be trivially parsed to extract out the semantically meaningful URIs.
>> 1. Constraining REST verbs to POST/GET
> As for restricting to POST/GET, that's the wrong direction to be
> in, just look at Web Forms 2.0 for what's coming in the next
> of HTML.
Great! I'd love to have more semantics to work with. Unfortunately,
the goal of *this* encoding is finding something that works with
today's browsers. The necessarily implies a *subset* of REST
functionality, which may be not be appropriate for all uses.
You're welcome (even encouraged) to propose something that will work
better in the future; I'm worried about doing something that works
>> 2. A system for constructing URLs.
> There are already several systems for construction URLs
That's my point. :-) With HTML, there's only one, which is a useful
>> 3. Discovery through URL construction as opposed to hypermedia.
> Hypertext as the engine of application state is an important
> concept, one I've written an entire article on .
I'm not sure I understand, but I think we're in violent agreement. I
am arguing for a *convention* on how to interpret URLs, so human's
can more readily understand them. I agree the system itself should
not hard-code specific URL interpretations.
>> 4. Limiting transfer representations to application/x-www-form-
> I'm not gonna really comment on that except to point out that
> uploading a video encoded in application/x-www-form-urlencoded
> is going to be a bit wasteful.
That was a red herring: of course browses support mime multi-part, so
REX should too.
> I've got my own ideas about how microformats intersect
> with RESTful web services that I've outlined in ,
> in general seeing everything through my Atom colored
>  http://bitworking.org/news/What_do_you_see_in_Web_2_0_
So, if I understand you correctly, you're arguing for applying
microformat principles to Atom, and using that as the generic carrier
for web services?
I don't have anything against that, but I'm unclear on what (if any)
advantage that has over using XOXO/XHTML as the carrier. Especially
since, much as I like Atom, I don't see it nearly as widely deployed
(much less readable) than HTML.
If there's something specific you can do in Atom I can't do in XOXO,
I'd love to find out what that is, so I know where my boundary
-- Ernie P.
Ernest N. Prabhakar, Ph.D. <drernie at opendarwin.org>
Ex-Physicist, Marketing Weenie, and Dilettante Hacker
Probe-Hacker blog: http://www.opendarwin.org/~drernie/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the microformats-rest