I can second having used net/url to call simple REST APIs, though
apparently slightly differently than Alex: I typically use
`http-sendrecv/url` to do the data-fetching (rather than `get-pure-port`,
and I build instances of the `url` struct directly rather than using
`format` and `string->url`. You'll want to look at the net/uri-codec module
if you need to build url elements from arbitrary input.
I do typically wrap the details in a library, even if it's just a
one-module "library" used only for that specific larger project. At a
minimum, I strongly suggest defining some data types for the return values
rather than just returning the raw hash-tables from `read-json`.
I think the specifics of what Racket-level interface to present to clients
is influenced a lot more by the specific API you're wrapping than by the
fact that it uses REST/HTTP under the hood. I do concur with your sense
that the most common thing is provide functions (make-client, client-login,
etc.) rather than objects.
A detailed discussion of the pros and cons of the class-based object system
would quickly get off topic, but I have come to appreciate it and certainly
wouldn't avoid it on principle. (I say that as the rare person whose
background was never OOP-by-default.) I affirmatively *would* use it when
you want inheritance or other object sorts of features, and I also find it
helpful when my values have many private fields. You can, of course, use
objects internally but not expose their nature as objects to client code: I
believe the db library does that extensively. There are also plenty of
things I dislike about the object system, though, and, if you're
considering it, I would definitely also evaluate whether racket/generic
meets your needs.
Unfortunately most of the code I've written to wrap REST APIs consists of
small internal things that I haven't released publicly. I think the only
thing I have published is my package for OpenCPU, an API for calling R
functions over HTTP (http://docs.racket-lang.org/opencpu/index.html).
However, I offer it only as an illustration of what I did in that specific
case, not as an example of outstanding library design. I published it in
case it might be useful to anyone, but I'm not actively developing it and
have never used it in production: I convinced my collaborators to implement
the functionality we wanted in Racket instead of R. Also, OpenCPU is a
pretty strange API. If I ever develop it further, there are design aspects
I'd want to address: I ideally would have loved to provide a higher-level
DSL like `_fun` from ffi/unsafe to deal with the marshalling to/from JSON,
On Wed, Apr 11, 2018 at 9:33 PM, Alex Harsanyi <alexharsa...@gmail.com>
> I used the built-in url package (http://docs.racket-lang.org/net/url.html)
> from Racket to fetch data from Wunderground weather API and it was simple
> enough that I did not feel the need for a separate REST library. I just
> used `format` to construct the URL, `get-pure-port` to fetch the data and
> `read-json` to parse it. The API that I used has an API KEY and only GET
> requests, so no login is required, however looking at the URL package,
> there are functions for POST requests and you can pass headers as well.
> If you want to look at my code, it is linked below, but the majority of
> that file deals with weather data management and only a tiny part is
> actually related to fetching data from the weather server:
> Best Regards,
> On Thursday, April 12, 2018 at 2:36:50 AM UTC+8, Paulo Matos wrote:
>> I am interested in developing a Racket wrapper for hetzner cloud rest
>> api. This is a REST API defined in:
>> I however, have no experience with accessing REST APIs in racket much
>> less developing one.
>> 1. Are there any examples out there of wrapping rest apis in racket?
>> 2. If you look at how this is done in Python as expected everything
>> is an object. However, from what I generally see, libraries seem to
>> rarely touch the racket object system (although I think it's great). So,
>> I guess instead of having an object 'Client' to which you would do (send
>> client login "username" "password"), is it generally preferable to have
>> a (make-client ...), which you would follow with (client-login
>> "username" "password")?
>> Any thoughts would be appreciated before I commit myself, only to find
>> it goes against the racket way once I publish it. :)
>>  https://github.com/elsyms/hetznercloud-py/
>> Paulo Matos
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.