World: r3wp

I've only ever used RSP with Cheyenne.

though I did build a smtp server using Uniserve once ....

Prior to today, the only thing I knew about REST was that it existed. 
 Now, ... I'm thinking that it might just be the way to go to provide 
web services for non REBOL clients.

The trick is that many HTTP clients only support GET and POST.

which is why I was hacking the http protocol recently to add the 
others

Presumably javascript supports all http verbs?

I wouldn't presume that - test first.

Or look it up.

is this the way to support all clients ?  from cellphones, to pdas 
and then full featured client browsers

well i only used get and post so i can't tell the others options

If you only use get and post, you can't do REST - it requires the 
others.

Handheld devices may be another matter. Many of them have poor JavaScript 
support, and most don't support XMLHTTP.

Those might require old school HTML get/post interfaces.

Which can also be implemented as Cheyenne proxies to your same LNS 
service.

how would one use cheyenne to load/balancing redistributing the resources

Cheyenne docs look a bit sparse ... the wiki sections are all looking 
for an author except for RSP. http://cheyenne-server.org/wiki/Main/HomePage

Docs: I put the wiki online mainly because several peoples asked 
me for one so they can contribute by documenting Cheyenne...

REST: The starting point is to authorize all HTTP methods by adding 
them in mod-static/method-support callback. Then, if Cheyenne doesn't 
choke on them (should be treated by default as a GET, but untested), 
you can write a dispatching RSP page that will basically do a : switch 
request/method [GET [...] POST [...] DELETE [...] ...]. The upcoming 
v0.9.19 release will bring a URL aliasing feature that will allow 
nicer and more RESTful URL.

so people asked for a wiki and then don't contribute?

Load balancing: if you're using RSP, you got it for free as each 
RSP is executed in its own separated process.

I think Brian was talking about using Cheyenne to do load/balancing 
for another application

as a proxy

maybe the one that asked are now too busy...anyway, the wiki was 
a good testbed for enhanced PHP support in Cheyenne.

method-support: func [req][
		if not find [HEAD GET POST PUT] req/in/method [
			req/out/code: 405
			return true
		]
		none
	]

Proxy: it can be done but requires a little more work, like building 
your own mod-something and implementing an async client protocol 
in Uniserve (unless you want to use the built-in HTTP async client 
protocol).

missing DELETE, OPTIONS, and FOO

just extend the method block list with whatever method you need

so, how would one determine if it's a REST request or just a ordinary 
other request?

the restriction on method was done mainly for security reasons (no 
appropriate default handler for other methods except these 4). PUT 
is treated by default like POST.

REST = HTTP request, so it depends on which handler will respond 
to the HTTP request. If your URL point to a .rsp => RSP handler.

Ok.

So, this is very doable then?

So your REST URLs have to point to a .rsp resource.

Well, in theory, yes :-)

I see that Deki uses query parameters on their PUT methods

is that standard?

If you need the HTTP client for Uniserve, just let me know, I have 
a much more recent unreleased version that should work better than 
the old one in Uniserve 0.9.9.

sure ..

I guess that the HTTP method and URI query parameters are not related.

what I read is that parameters are supposed to be sent as custom 
headers with PUT

but I guess that's harder to process

from RSP, you just have to look in request/headers to get custom 
headers.

what do you mean the REST URLs have to point to a rsp resource?

with REST you don't have a static page to point to

for now, if you want that your requests be processed by Cheyenne, 
you have to.

Async HTTP client for UniServe: http://softinnov.org/tmp/HTTP-client.zip

T'hanks.

HTTP.r shoud go in UniServe/protocols/, libs/ should go in UniServe/

Need to go now...

ok, thanks ..