The new type of the watcher for the API monitoring is already available. Actually, it has much in common with the website watcher (very akin configuration, and under the hood uses the HttpClient as well), however it does serve a different purpose, which is making the request to the API and validating its response, whereas the website watcher basically pings the given url (well, it can validate its response too), and does not really care about any other HTTP method different than GET. In this POST (did you get the joke?), I’ll present how to use the API watcher with the help of code examples.
Let’s begin with the simplest configuration possible:
1 2 3 |
var configuration = ApiWatcherConfiguration .Create("http://my-api.com", HttpRequest.Get()) .Build(); |
This “single line of code” (you can make it a single line, trust me) is pretty much everything you need for a simple monitoring of the API for the given URL: http://my-api.com. Certainly, we can push that configuration into being a little bit more sophisticated:
1 2 3 |
var configuration = ApiWatcherConfiguration .Create("http://my-api.com", HttpRequest.Get("users/1")) .Build(); |
In the scenario above we’re stating that for the given base URL of the API (http://my-api.com), we want to monitor its endpoint: users/1.
Let’s asume now that this HTTP request returns the user object (in the end it’s a GET call, so it should return something), and we want to make sure that this resource is correct:
1 2 3 4 5 6 7 8 9 10 11 12 |
var configuration = ApiWatcherConfiguration .Create("http://my-api.com", HttpRequest.Get("users/1")) .WithHeaders(new Dictionary<string, string> { ["Accept"] = "application/json", }) .EnsureThatAsync(async response => { var user = await response.Content.ReadAsAsync<dynamic>(); return user.name == "admin"; }) .Build(); |
And this is where the things start to get a little bit more interesting. At first, we’re setting the Accept header in order to consume the resource of the JSON type, and next we’re deserializing that JSON (in that example into dynamic object, but of course it can be any class) and validating the username. And what about the other HTTP methods such as POST, PUT, DELETE? Here comes the anwser:
1 2 3 4 5 6 7 8 |
var configuration = ApiWatcherConfiguration .Create("http://my-api.com", HttpRequest.Post("users", new {name = "test"})) .WithHeaders(new Dictionary<string, string> { ["Authorization"] = "Token MyBase64EncodedString", }) .EnsureThat(response => response.Headers.Location != null) .Build(); |
Firstly, we’re defining the new POST request to the endpoint “users” and passing a new object that contains the name = “test”. Next, we’re setting the Authorization header (let’s say that your API makes use of the Token Authorization) and finally, we’re checking whether the received response has the valid Location header (as it’s a good practice to return the URL with the location of the resource after the POST request was executed in theRESTful API).
Voilà, that’s it! And of course, do not forget to create a new instance of the API watcher and add it to the Sentry before you actually start using it:
1 2 3 4 |
var apiWatcher = ApiWatcher.Create("My API watcher", apiWatcherConfiguration); ... sentryConfiguration.AddWatcher(apiWatcher); ... |
I hope that not only will you find that but also the other watchers useful, as there are many more coming soon (you can check my ideas on the GitHub).
Pingback: dotnetomaniak.pl