Netumo Black Friday offer is now available. Use coupon BLACKFRIDAY21 at checkout to get 50% off any plan. (This offer is not redeemable with any other offer)

RESTful Monitoring

A RESTful API (also known as REST API) is an application programming interface (web API or API) that conforms to the constraints of REST architectural style and allows for interaction with RESTful web services. REST stands for representational state transfer and underlyingly utilizes the HTTP/S protocol.

RESTful monitoring in Netumo is a feature specifically designed for web service and web applications that are built using such APIs. RESTful monitoring in Netumo is possible with the creation of monitors for RESTful URLs, similar to website monitoring but take different parameters.

RESTful APIs can either require authentication or allow anonymous calls. In the case of anonymous calls then the REST monitor can work on its own without any additional requirements however for REST APIs that require authorization then Netumo requires the token and also the ability to fetch such a token. Typically tokens are generated with another REST API call with a normal username and password.

How does Netumo RESTful monitoring work.

Before Netumo performs the RESTful monitor call, it will ensure that it has all of the required data, and in case of an authenticated RESTful monitor call it will require the authentication data or token.

The data/token is typically obtained via another RESTful call which would have some form of more readable form such as username and password. 

Prior doing the RESTful monitor call Netumo will trigger the REST Auth call to update the token. The REST Auth call can be done each time, i.e. before the REST monitor call or else only once in a while, and the token used for subsequent calls. In case the server returns an updated token then Netumo will use that for subsequent REST monitoring calls.

Each RESTful monitor URL consists of the following:

Request
Verb HTTP Verb: GET, POST, PUT, DELETE, OPTIONS etc.
URL URL of the RESTful service
Headers Additional headers to send with the request. 

In the case of custom, authentication the string {NETUMOTOKENAUTH} will be replaced with the token fetched via the Authentication method.

Body Body value to send in case of POST / PUT etc.
Authentication Authentication method based on Authentication table below
Match Criteria (Response)
Status Code Match the status code
Body Match any substring in the body
Headers Match any substring in the headers

Authentication

 

Request
Verb HTTP Verb: GET, POST, PUT, DELETE, OPTIONS etc.
URL URL of the RESTful Authentication service
Headers Any additional headers to send
Body Body value to send in case of POST / PUT etc.
Response
Authorization Type Bearer Token, Basic, Digest, or Custom
Token Location The location of the token – Header, or Body (JSON or XML)

Example 1 – JWT

Header

The token is present in the Authorization header.

Example 2 – OAuth2

JSON Body

The token is present in JSON body

Token Property The property where the token is located

Example 1 – JWT

Authorization

The token is present in the Authorization header.

Example 2 – OAuth2

access_token

The token is present in JSON body

A REST Authentication property can be used by multiple RESTful monitoring however in case of situations where the token changes with each request then it is suggested to only use a REST Authentication property per RESTful monitor.

The Authentication token can be refreshed as required. It can be refreshed with each request or after a period of time. It is suggested to set to refresh after a couple of days prior your token expires.

Body Variables

There are situations where data and time need to be added to the request body being sent in RESTful requests which would not need to be static when configuring the monitor. This can be achieved by adding Netumo monitor variables. Such variables are computed exactly before the monitor is being sent.

The variable format is the following:

[[NETUMOVAR][<format>]<adjust><hour|minute|second|days>]

Where

  • <format> is the date-time format to use. We use Microsoft .NET format specifiers using en-US culture.
  • <adjust> would be the time adjustment like +1 to add 1, or +0 for no change or -1 to subtract 1.
  • <hour|minute|second|days> would be if the time adjustment is in hours, minutes, second or days. This is specified in h, m, s or d

Example

[[NETUMOVAR][g]+1h]

would translate to “10/31/2008 5:04 PM” assuming it was run on the 10/31/2008 at 4:04 PM (UTC)