guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: http-post


From: Andy Wingo
Subject: Re: http-post
Date: Fri, 11 Jan 2013 15:44:44 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

On Tue 17 Apr 2012 05:34, gregory benison <address@hidden> writes:

> "More helper procedures for the other common HTTP verbs would be a
> good addition to this module.  Send your code to <address@hidden>."
>
> 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/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]