This is background research into current saturation test tools that work over HTTP. This domain is suited to E2E testing, but generally excludes any client side stuff, as the client doesn't need to scale that much. For test purposes, I would setup the tool on the same host as the webserver, so results on different test scenarios are more reliably comparable.
I'm writing this, as today I wrote another test runner to be able to send API requests in bulk; and think this is misplaced effort.
Requirements for the tools:
- can talk HTTPS
- can authenticate self at start of script (via a login request; or HTTP auth, if essential)
- will understand full range of HTTP response codes
- can send each HTTP verb 
- provides control on request population
- provides summaries of results
- ideally has basic support for JSON and XML parsing, to be able to understand inline error codes from API that aren't REST 
- can be linked into a CI
- can do floods of requests, not singular ones
- General articles on stress tools 1 2
- Requester, env: sublime text editor/Python.
- Postman, env: some cloud server + your Chrome instance
- SoapUI, env: Java/Maven.
- Rapise env: java
- This looses marks for being win32 only but written in Java
- This seems to be an interactive HTTP client, with JS, but without media support. Like a HTTP-REPL.
- This looks like a strong contender with Selenium.
- supports authentication ~ roughly, but the docs only mention BASIC auth status codes ~ roughly the manual only mentions HTTP200 ✔ response parsing ✔ http verbs ~ roughly, the manual only mentions GET and POST populations ✔ CI integration ✔ (roughly, they want to hype their own scheduler tools)
- Gatling env: scala
- SOAtest env: .Net
- docs 11 12 13 14 manual on scribd 15
- This tool is quite focussed on XML, not REST.
- They are waving the word “licence” around a lot.
- supports HTTPS ✔ supports authentication ~ read the link, they are focussed on XML RPC certs, not user accounts. Response parsing is not in the manual at all, although. No mention of http verbs populations ✔ CI integration ✔
- vREST env: Node
- JMeter env: I suspect C
 I am being careful with GUI on this point. If I am using cURL, I can type a short string for the verb, and may use anything. In a GUI, I will be pressing a button, and there may only be “GET” or “POST” as options.
 Not my work obviously. Adding “does this match the documentation” tests to third party API is never a bad thing. It doesn't take long with correct tooling, and will save much more time debugging integrations. Most of the vendors I'm talking to after 2013 have a REST API not a random RPC API or webscraping.