On Tue 17 Apr 2012 05:34, gregory benison <gbeni...@gmail.com> writes:
> "More helper procedures for the other common HTTP verbs would be a
> good addition to this module. Send your code to <guile-user@gnu.org>."
>
> So, I say to guile-user, "here is my code".
Thanks! I used it as a base for a patch I just pushed. Guile now has
client wrappers for all HTTP verbs except CONNECT. Appending the
documentation. A websocket implementation would be nice.
> I think the next steps after this patch are to:
> - be able to work with a greater variety of encodings;
> - since form data of the type "key1=value1&key2=value2..." is so
> common in POST bodies, accept post data as key-value pairs represented
> by an alist (which would be coerced into a bytevector automatically).
Yes this would be good. Want to make a patch?
Regards,
Andy
File: guile.info, Node: Web Client, Next: Web Server, Prev: Responses, Up:
Web
7.3.8 Web Client
----------------
`(web client)' provides a simple, synchronous HTTP client, built on the
lower-level HTTP, request, and response modules.
-- Scheme Procedure: open-socket-for-uri uri
Return an open input/output port for a connection to URI.
-- Scheme Procedure: http-get uri keyword-arg...
-- Scheme Procedure: http-head uri keyword-arg...
-- Scheme Procedure: http-post uri keyword-arg...
-- Scheme Procedure: http-put uri keyword-arg...
-- Scheme Procedure: http-delete uri keyword-arg...
-- Scheme Procedure: http-trace uri keyword-arg...
-- Scheme Procedure: http-options uri keyword-arg...
Connect to the server corresponding to URI and make a request over
HTTP, using the appropriate method (`GET', `HEAD', etc.).
All of these procedures have the same prototype: a URI followed by
an optional sequence of keyword arguments. These keyword
arguments allow you to modify the requests in various ways, for
example attaching a body to the request, or setting specific
headers. The following table lists the keyword arguments and
their default values.
`#:body #f'
`#:port (open-socket-for-uri URI)]'
`#:version '(1 . 1)'
`#:keep-alive? #f'
`#:headers '()'
`#:decode-body? #t'
`#:streaming? #f'
If you already have a port open, pass it as PORT. Otherwise, a
connection will be opened to the server corresponding to URI. Any
extra headers in the alist HEADERS will be added to the request.
If BODY is not #f, a message body will also be sent with the HTTP
request. If BODY is a string, it is encoded according to the
content-type in HEADERS, defaulting to UTF-8. Otherwise BODY
should be a bytevector, or `#f' for no body. Although a message
body may be sent with any request, usually only `POST' and `PUT'
requests have bodies.
If DECODE-BODY? is true, as is the default, the body of the
response will be decoded to string, if it is a textual
content-type. Otherwise it will be returned as a bytevector.
However, if STREAMING? is true, instead of eagerly reading the
response body from the server, this function only reads off the
headers. The response body will be returned as a port on which
the data may be read.
Unless KEEP-ALIVE? is true, the port will be closed after the full
response body has been read.
Returns two values: the response read from the server, and the
response body as a string, bytevector, #f value, or as a port (if
STREAMING? is true).
`http-get' is useful for making one-off requests to web sites. If
you are writing a web spider or some other client that needs to handle a
number of requests in parallel, it's better to build an event-driven URL
fetcher, similar in structure to the web server (*note Web Server::).
Another option, good but not as performant, would be to use threads,
possibly via par-map or futures.
--
http://wingolog.org/
