[uf-rest] Fwd: [microformats-discuss] REX! Re: REST-discuss list, naming

[Dr. Ernie Prabhakar]

Hi all,

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  
> moving
> in, just look at Web Forms 2.0[1] for what's coming in the next  
> version
> 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  
today...


>>   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  
constraint.

>>   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 [3].

[3] http://www.xml.com/pub/a/2005/04/06/restful.html

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- 
>> urlencoded
>
> 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 [4],
> in general seeing everything through my Atom colored
> glasses.

> [4] 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  
conditions are.

Thanks,
-- 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...
URL: http://microformats.org/discuss/mail/microformats-rest/attachments/20051031/62d0587b/attachment.htm