13

Is there any reason to avoid using rest-assured in a non-testing-environment? The syntax the library offers for creating and parsing requests is so compact it seems a waste to only use it in testing. Which kind of begs the question, why is it targeted as a testing tool alone?

eladidan
  • 2,634
  • 2
  • 26
  • 39

1 Answers1

25

I'm the founder of REST Assured and it has always primarily been targeted towards testing. For example the default port is 8080, it ships with Hamcrest matchers (which is used internally as well so it cannot be excluded) and performance could probably be optimized somewhat. It also depends on Groovy which can be quite a large dependency to add to a production system if all you need is an HTTP client.

People, including myself on occasion, are using it in production because it's easy and flexible to use. Not all use cases require state of the art performance with a minimum number of dependencies. So for certain bounded contexts REST Assured will probably make a lot of sense.

One of my goals with REST Assured is to extract a more lightweight core and remove the need for Hamcrest and potentially even Groovy in the future. Some steps have already been taken in this direction when JsonPath and XmlPath were extracted to their own projects.

Johan
  • 37,479
  • 32
  • 149
  • 237
  • 1
    I don't think I could've hoped for a better response than this. The long term goal of extracting core functionality from the project sounds like a fine one. – eladidan Oct 22 '14 at 16:45
  • 1
    What's the status on this lightweight version? I also find the API better than other clients I've used and would like to use it for production code :) – Ruben Mar 03 '17 at 12:24