Lately I’ve been diving into API mocking more as I wanted to reproduce some scenarios on my local environment due to not being able to on the remote machines I was given access to. The few people I talked to about it came up with a few different free tools; castlemock and wiremock. Having only heard of wiremock but having never really tried either of them I had a go at running both. But in the end I ended up choosing another tool entirely.
Let’s docker
As an additional challenge I thought it would be fun to create custom docker image of a tomcat server which automatically deployed both the castlemock and wiremock .war files. While completely unnecessary it’s a nice basic training exercise as I do not get to work with docker esque software as often as I’d like. Instead of just pulling the wiremock and castlemock docker images I instead wrote this small dockerfile:
FROM tomcat:10.1.20-jdk21 LABEL maintainer="work@woutermail.nl" RUN cp -avT $CATALINA_HOME/webapps.dist/manager $CATALINA_HOME/webapps/manager ADD https://github.com/castlemock/castlemock/releases/download/v1.67/castlemock.war /usr/local/tomcat/webapps/
It took a few tries to get this running correctly, I also ran into the issue that when you install docker into WSL2 directly I couldn’t quite get everything reachable for testing as I’d like. When I switched to docker for windows integrated into WSL2 it all worked fine on the first go. I’m not 100% sure whether this is was my fault or whether it’s an inherent issue with WSL2 + Docker but it worked in the end nonetheless. As a final step I added the container to a docker compose to refresh my basic knowledge of how that worked. Sidenote: the manager UI is not enabled by default anymore in tomcat so that’s why I had to configure those two files via the volumes.
services: tomcat: image: tomcat-localmock:1.0.0 ports: - "8080:8080" volumes: - ./tomcat-users.xml:/usr/local/tomcat/conf/tomcat-users.xml - ./manager-context.xml:/usr/local/tomcat/webapps/manager/META-INF/context.xml environment: - ALLOW_EMPTY_PASSWORD=yes
Castlemock
Castlemock is a webservice which can be run in an application server like Tomcat. You just have to throw the .war file in there and you’re good to go mocking! On paper this was fine for what I was looking for, with the additional benefit of it also supporting SOAP. Unfortunately I’m not so easily content with the solutions I choose. I prefer to use a tool I would also be able to use in a real scenario for a customer I’m working for. This gives me the benefit of learning extra skills on the job which is always useful!
Wiremock
Wiremock is a widely used mocking enginee which can also be run in tomcat or the like. It well developed api you can send data to from a variety of languages. For my case I would just send a json file to it via a POST request. While pretty easy use, it does require me to translate my OAS file to a wiremock format before I can mock something.
{ "request": { "method": "GET", "url": "/some/thing" }, "response": { "status": 200, "body": "Hello, world!", "headers": { "Content-Type": "text/plain" } } }
(Un)Fortunately I’m a lazy developer and I just want to serve my api spec to a tool which then automatically mocks that API for me so the search went on.
If not those, what then?
After some more searching I ended up on the Stoplight website. I didn’t know stoplight had more opensource solutions than just the OpenAPI file linting solution spectral apart to their main paid platform (which is also very conveniently implemented in WSO2 AM 4.2.0 and up) . But lo and behold they also have a product called “Prism” which does exactly what I’m looking for! Prism allows you to just spin up a docker container with an attached openapi spec and then magically mocks the entire api for you including validation. Looking at the prism docu it seems that by design you’re supposed to host a single openapi spec per prism instance. This sounds pretty handy as you can easily segment and start running a bunch of different api backends whenever you need by just adding extra containers. To keep with the spirit of the earlier examples I tried to create my own dockerfile for this example again. All it does is copy the api spec into the docker container ahead of time. Using this setup you could technically automate this into a pipeline somewhere so that whenever you update your api spec it automatically renews your mock service. Perhaps I’ll do that as a learning exercise at some point.
FROM stoplight/prism:5 LABEL maintainer="integration-adjacent@proton.me" COPY api-spec.yml /usr/src/prism/ CMD ["mock","-h","0.0.0.0","/usr/src/prism/api-spec.yml"]
The API spec i’ve used here is the great OAS example from bump.sh called the “Train travel API”, this is a better example than the notorious Petshop API that pops up everywhere due to it being the default on the openapi website.
When you start up this container image you are greeted by the following:
docker run prism-train [9:40:49 AM] › [CLI] … awaiting Starting Prism… [9:40:50 AM] › [CLI] ℹ info GET http://0.0.0.0:4010/stations [9:40:50 AM] › [CLI] ℹ info GET http://0.0.0.0:4010/trips?origin=efdbb9d1-02c2-4bc3-afb7-6788d8782b1e&destination=b2e783e1-c824-4d63-b37a-d8d698862f1d&date=2024-02-01T09%3A00%3A00Z [9:40:50 AM] › [CLI] ℹ info GET http://0.0.0.0:4010/bookings [9:40:50 AM] › [CLI] ℹ info POST http://0.0.0.0:4010/bookings [9:40:50 AM] › [CLI] ℹ info GET http://0.0.0.0:4010/bookings/1725ff48-ab45-4bb5-9d02-88745177dedb [9:40:50 AM] › [CLI] ℹ info DELETE http://0.0.0.0:4010/bookings/1725ff48-ab45-4bb5-9d02-88745177dedb [9:40:50 AM] › [CLI] ℹ info POST http://0.0.0.0:4010/bookings/1725ff48-ab45-4bb5-9d02-88745177dedb/payment [9:40:50 AM] › [CLI] ▶ start Prism is listening on http://0.0.0.0:4010
All good to go and able to be used as a mocked back-end! I love it when things are as simple as I want them to be. Kudos to the devs at Stoplight.
But what if I want more mocks quickly?
Of course this docker image build is good in some automated setup but what if I just want to spin up a few mock backends on the file myself? I figured it would be better to resort to docker compose in that case with just the default prism image instead of my own. You can specify the api spec that needs to be used on startup and can easily spin up multiple containers like this. This is great if you want multiples of the same API to test load balancing or failover. Or just spin up multiple different backends.
services: api1: image: stoplight/prism:5.7.0 command: 'mock -h 0.0.0.0 api-spec.yml' volumes: - ./api-spec.yml:/usr/src/prism/packages/cli/api-spec.yml ports: # Serve the mocked API locally as available on port 8080 - '8080:4010' api2: image: stoplight/prism:5.7.0 command: 'mock -h 0.0.0.0 api-spec.yml' volumes: - ./api-spec.yml:/usr/src/prism/packages/cli/api-spec.yml ports: # Serve the mocked API locally as available on port 8081 - '8081:4010'
Wrapping up
This was a fun learning journey, I feel this has opened quite a nice road into some more other learning adventures. I can definitely make use of this knowledge in my day to day work. If you know any other great API mocking tools please send me an email! I’d love to try it out. Thanks for reading and have a great day!
