Building RESTful APIs can make it easier to enforce certain decoupling rules, but it often imposes an additional infrastructural burden, depending on your tech stack. Lately, I’ve been struggling with some of the inconsistencies between our Bamboo-built Docker containers and the locally-compiled version of what should be exactly the same software: it’s not that the bytecode is different, but the boundary between the separately-Dockerized MySQL database and my code’s container was enough to give Hibernate fits until I figured out the necessary library import.
Furthermore, even serving requests via HTTP can be different. One potential pitfall is in CORS filtering, wherein the browser itself protects us from what appears to be a different (possibly malicious) domain. My testing in Paw, an OS X REST client, worked just fine. My coworker tried to hit the deployed API from Chrome and got no result. The confusion was brief, but it’s still a bit of friction.
The linked blog post above describes the concept effectively, but it’s targeted at an older version of Play, using Scala. We’re using Play 2.4 and Java.
Fortunately, once the term ‘cors’ is in your googlesearch toolbox, you’re able to find Play’s documentation on the subject. In order to open the API wide for development purposes, I added the following to our application.conf:
# CORS filter configuration
allowedOrigins = ["*", ...]
allowedHttpMethods = ["GET", "POST", "OPTIONS", "PUT"]
allowedHttpHeaders = ["Accept, x-requested-with, content-type, Cache-Control, Pragma, Date"]
preflightMaxAge = 90 days
Which allows us to make a browser request and see the expected JSON without having to fire up Paw.