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, for example. -Philip On Wed, Apr 11, 2018 at 9:33 PM, Alex Harsanyi <alexharsa...@gmail.com> wrote: > > 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: > > https://github.com/alex-hhh/ActivityLog2/blob/master/rkt/weather.rkt#L239 > > Best Regards, > Alex. > > > On Thursday, April 12, 2018 at 2:36:50 AM UTC+8, Paulo Matos wrote: >> >> Hi, >> >> I am interested in developing a Racket wrapper for hetzner cloud rest >> api. This is a REST API defined in: >> https://docs.hetzner.cloud/ >> >> 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[1] 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. :) >> >> [1] 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 to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
