Testing at the API level is quite possible, and usually well worth the effort, especially when there are multiple consumers for that API, or if the API is available for public use. There is a related question/answer you might want to read through here: How do you test a backend API
As far as tools for a REST web service, there are a number of options. You can use:
- A GUI tool such as SoapUI
- Load/performance testing tools like Jmeter.
- Simple manual testing using tools such as Postman (chrome plugin).
- Write automation code using HTTP and JSON libraries for your favorite programming language
The approach I have taken, which may be a good approach if you or someone on your team can write code would be to use an HTTP and JSON library. Examples for C# would be the built in .net http request and json.net. Examples for Java would be Apache httpclient and Jackson. You will also be using a tool like Fiddler, HTTPWatch, or Wireshark or one of the built in http traffic watchers in the browser developer tools to get the request information you need to build the requests.
The approach I typically take is:
- Create basic requests to all of the service endpoints
- Create a json schema (See http://json-schema.org/) to validate responses.
- Create specific test cases to validate the REST API behavior and assert on expected response values
- Record traffic from all of the known existing clients and create test cases based off of that traffic.
- Create additional tests taking into consideration potential future use of the API and edge cases.
The good thing about the json schema is that you create a contract, and get feedback immediately when that contract is broken. This would be useful for the monitoring you mentioned in your question. You could have a set of simple tests that run on a schedule and validate that the response is a 200 response code and the json returned complies to the schema.