Instead of memoizing slurp, you could have a look at core.cache, it could be a useful tool for other things as well.
Wrt the functions, the naming might be better (filter-all-objectNumbers does no filtering at all, and arguably, could just be a lambda in the last pipeline…)
But that is not filtering, in FP parlance (and so the name will be misleading in a Clojure codebase). Filtering you do with filter and related functions, and those generally will take things out of a collection, not select keys from a map.
Re: the lambda, is that a one-liner function that is self descriptive could just be inlined in (fn..) form. It’s good to name things, in general, but in many cases, lambdas are more idiomatic.
If you’d like to use this project to learn some libraries and how you’d do this “properly” (for some value of “proper”), you might want to look in to http-kit or clj-http, for making your requests (rather than manually building the URL and slurping it), core.cache for the caching (though ATM I don’t see why you’d be caching this, since you basically request everything only once)
Also, what I mentioned about the lambdas, you could write something like this when you’re prototyping this at the REPL:
Your filters functions are simply wrapping maps methods, you can unwrap them and use directly in your thread-macro.
The final result by the way is really similar but, instead of retrieving all object numbers and iterate each one to search the correct image to associate, i simply handle this operation within the object-number image retrieval.
Hope you’ll find this useful.
Caching could be working on another level. This will be a multipage website and maybe it can be wise to “cache” the image fetching part so the next time the same page is asked and the same images has to be shown it coming from the “cache” instead of every time asking the api for all the data.
Thanks for showing me.
This could be working but I have to see how I can make another call where I fetch some data later if a user wants to see that data.
You probably need to extract the :body of the response before trying to access its contents.
You should get in the habit of exploring the results you get from the REPL.
I’m not sure how is it with Calva, but in CIDER there’s a very useful command that evaluates an expression and pretty-prints the results, which is very handy for this type of stuff.