I’ve inherited a legacy REST API that’s largely undocumented, but I also have the accompanying legacy web app that consumes it. I’d like to document and specify that API so I can start writing tests and changing implementations etc. I was looking around for tools to help with that, but couldn’t find any.

I was thinking of putting a proxy between client and server, which would let requests pass through but also log them so then I can look for similarities etc, and generate some crude spec from it. Does that sound reasonable?

Why not just add logging to the server? (or client)

The amount of spaghetti code in both codebases is a thing to marvel at. I’d rather treat them both as black boxes to begin with.

Also, the major issue the org is having is lack of an explicit contract between client and server.

(This is a node/mongo/jquery combo that is 5 years old - it’s not a platform I want to touch... yet)

I was thinking I’d setup this proxy, click around in the website, dump everything into a huge edn file and then use Clojure to explore the data interactively.

I see, maybe non-intrusive observing is the best approach then. 🙂 I’ve used this with Node to capture HTTP-calls. It can also output them as data (JSON). It may or may not be useful in your case. https://github.com/nock/nock#recording

Ah, mocking is a good keyword to search for. Thanks!

For PR reasons, I believe we should rename functions to “nanoservices.”

hm, interesting https://www.sencha.com/blog/java-web-frameworks-survey-results/

Anyone here by any chance doing the exercises from HaskellBook?

@victor.cleja Yeah, I thought that Gradle is more popular

Gradle can be intimidating.

I think Gradle is great, you can use plain Java in Groovy, I've never tried sbt (https://www.scala-sbt.org/)

but sbt landed in "other" I guess