This section assists software developers who want to develop applications by using Dotcom-Monitor monitoring tools.
There are several ways to view and interact with monitoring data beyond the Dotcom-Monitor website interface, including using the XML feed to consume data and interacting with the Dotcom-Monitor API to monitor and update installed monitoring agents.
With the XML feed, developers can subscribe to the wanted data and present it in their own format using their own custom reports. See Using the XML Reporting Service (XRS) Tool for details.
The Dotcom-Monitor API users can create their own custom scripts or applications to interact with the settings and view the monitored data in their own customized environment. Our system uses REST API that enables interaction with the Dotcom-Monitor web site programmatically using the most popular methods for working with data via HTTP(S) requests (GET, POST, PUT, DELETE). Almost all Dotcom-Monitor objects can be accessed via REST API and almost every aspect of Dotcom-Monitor service functionality can be managed. Using API calls the developers can create and remove devices and tasks, postpone and start them, create and manage alert groups, templates, filters and schedulers, obtain device status information plus many other options.
In general, the Dotcom-Monitor API can be used in the following tasks:
- Third-party integration with the Dotcom-Monitor Monitoring solution.
- Data download and upload.
- Data modification.
The most common actions executed via the REST API:
- Accessing lists of monitoring platforms, devices, targets, schedulers, locations, alert groups, filters, alert templates.
- Accessing detailed info on platforms, devices and targets.
- Editing devices, targets, schedulers, alert groups and templates, filters.
- Creating a new dotcom-Monitor object ( devices, targets, schedulers, etc.).
- Managing audit objects.
Custom Collector API
Separate MetricsView API is a set of methods for uploading any metrics from any source regardless of a platform into Dotcom-Monitor inc. for further processing and analysis.
The Dotcom-Monitor API is broken out into 10 resource types:
- Platform: All monitoring tasks fall into one of five different platforms.
- Devices: A monitored device is an organized “set” of monitoring tasks that contains either a single monitoring task, a sequence of monitoring tasks, a monitoring script that includes tasks, or a combination of all three.
- Tasks: A task is any single monitoring activity, such as monitoring a target (URL, Mail Server, FTP Server, etc.).
- Frequency: Defines how often monitoring sessions will be executed.
- Scheduler: A scheduler details when a task will or will not be run.
- Location: A monitoring location available within the Dotcom-Monitor worldwide monitoring network.
- Alert Group: Setting up a group places recipients of a report and/or alert into a group. Each recipient in the group can have a unique alert template.
- Alert Template: Template defines alerts format.
- Filter: A filter is a set of rules, which determine how monitoring responses are processed and displayed.
- Audit: Provides historical information on each and any account modification.
You need to be authenticated in Dotcom-Monitor before any API request. Authentication expires after 60 seconds of inactivity.
The table below shows which request type and action are supported by each resource type. See the Monitoring Methods section for detailed descriptions.
| Resource type | Request Method | URI(s) | Description |
|---|---|---|---|
| Platform | GET | /platforms | Return list of available platforms |
| Device | GET | /devices/{platform} | Get device list by platform. |
| GET | /device/{deviceId} | Get Device info | |
| POST | /devices?verb=PUT | Create New Device | |
| PUT | /devices | ||
| POST | /device/{deviceId}/DisableAlert/ | Disable Alerts | |
| POST | /device/{deviceId} | Edit Device | |
| POST | /device/{deviceId}?verb=delete | Delete Device | |
| DELETE | /device/{deviceId} | ||
| Task | GET | /device/{deviceid}/tasks | Get list of tasks under a device |
| POST | /tasks?verb=PUT | Create new task | |
| PUT | /tasks | ||
| GET | /task/{TaskId} | Get task info | |
| POST | /task/{TaskId} | Edit task | |
| POST | /task/{TaskId}?verb=delete | Delete task | |
| DELETE | /task/{TaskId} | ||
| Frequency | GET | /frequencies/{platform_name} | Get available freq. by platform. |
| Scheduler | GET | /schedulers | Get list of schedulers |
| GET | /Scheduler/{Scheduler_ID} | Get specific scheduler info | |
| POST | /schedulers?verb=PUT | Create new scheduler | |
| PUT | schedulers | ||
| POST | /scheduler/{ scheduler ID} | Edit scheduler | |
| POST | /Scheduler/{Scheduler_Id}?verb=delete | Delete scheduler | |
| DELETE | /Scheduler/{Scheduler_Id} | ||
| Location | GET | /locations/{platform_name} | Get list of available locations |
| Alert Group | GET | /groups | Get list of alert groups |
| POST | /groups?verb=PUT/groups | Create alert group | |
| PUT | groups/groups | ||
| GET | /Group/{Group_ID} | Get alert group info | |
| POST | /Group/{Group_ID} | Edit alert group | |
| POST | /Group/{Group_Id}?verb=delete | Delete group | |
| DELETE | Group/{Group_Id} | ||
| Alert template | GET | /templates | Get list of alert templates |
| POST | /templates?verb=PUT/templates | Create new alert template | |
| PUT | /templates/templates | ||
| GET | /template/{Template_ID} | Get alert template info | |
| POST | /template/{Template_ID} | Edit alert template | |
| POST | /template/{Template_Id}?verb=delete | Delete template | |
| DELETE | /template/{Template_Id} | ||
| Filter | GET | /filters | Get list of filters |
| POST | /filters?verb=PUT | Create new filter | |
| PUT | /filters | ||
| GET | /filter/{filter_ID} | Get specific filter information | |
| POST | /filter/{filter_ID} | Edit filter | |
| POST | /filter/{filter_ID}?verb=delete | Delete filter | |
| DELETE | /filter/{filter_ID} | ||
| Audit | GET | /audit/list | Get list audited objects for current user for the last 24h. |
| GET | /audit/object/{sample ID} | Get contents of audit for the particular ID | |
| POST | /audit/list | Get filtered list of audited objects. |
-
Web API Monitoring: How to Start and What Approach to Use
Before we start with the Web API Monitoring topic, let’s talk briefly about the approaches that are commonly used to exchange data between different types of software.
It is hard to imagine a modern company where all business processes are running on a single software product. Generally, there are several desktop and web applications are used to support business operations through their entire life cycle. Some applications out of the box are able to interact with related software products, while others needs some additional configuration or third-party services. For example, the common practices that were introduced to the software market to support software integration are:
- Web services.
- File exchange via FTP.
- Unstructured HTTP requests.
- Other approaches such as web sockets, dedicated ports, etc.
While all other software integration approaches don’t have standardized processes of data exchange, web services provide standardized way of integration. A web service is a technology that allows applications to communicate with each other over a network. Simple put, a web service is an address on the Internet, a link that can be accessed to get data or perform an action. Typically web services that run over HTTP are called Web API. The advantage of using HTTP as a transport protocol is that it makes web services independent from programming languages. In the case of web services, the client making the request to the resource and the API server providing the response can use any programming language or framework. This way it does not matter if applications we want to connect are developed using the same programming languages or not.
Web APIs are usually implemented using the following technologies:
- XML-RPC (eXtensible Markup Language Remote Procedure Call) – the protocol that uses HTTP as a transport protocol and XML to encode calls.
- JSON-RPC (JSON Remote Procedure Call) – an analogue of XML-RPC except messages are transferred in the JSON format.
- SOAP (Simple Object Access Protocol) – the standardized protocol that uses WSDL (Web Services Description Language) based on XML to describe a message structure.
- REST (Representational State Transfer) – not a protocol but an architecture of software interaction in a network based on the methods of the HTTP protocol.
- Specialized protocols designed in order to work on a specific task, such as GraphQL that is used to create a query to an API server and load data from that API to a client application.
What is API Monitoring?
Once you implemented a Web API for your application and consider going on public, you need to make sure that all API functions work in accordance with the business logic of your application. Moreover, keeping tabs on your Web API performance is crucial irrespective whether you are a consumer of the API service yourself or you provide the service to third-party applications. Any degradation in your API service performance can cause significant losses for related businesses and affect your users experience.
The main purpose of API Monitoring is to proactively find and fix all the errors within your API as they occur and even before your users notice them.
Why do we need to monitor the API of your web application or web site? Why is the UI testing not enough to be sure that your web application works correctly? UI testing really is the best way to simulate real user behavior (see the advantages of web application testing in a real browsers with Dotcom-Monitor EveryStep Scripting Tool). However, web site functionality that we tend to monitor through UI generally can already be checked by API monitoring tests. For example, an API call that loads the list of items in-stock on the online store was changed on the backend but stayed the same on UI and the system will fail to return the list on corresponding user action on the web site. In this case, UI monitoring will return the error but the true source of the error won’t be detected (it can be a connectivity issue, server overload, UI errors, incorrect API call, etc.). On the other side, Web API monitoring will show that the call to the target API endpoint does not return the response. For additional API call result verification the response content validation can be used.
How Does API Monitoring Work?
Web API monitoring focuses on resources and access to these resources. In Web API, resources present different types of information. Resources can be accessed through URLs (Uniform Resource Locators). When you navigate to a particular URL in your browser, you connect to the resource that corresponds to that URL. The same happens when you send an API request to an URL address of the resource from such applications like Postman or using CURL. To make it clear for the web service what action you want to perform on the resource the HTTP methods are used including GET (read), POST (create), PUT (update), and DELETE (delete). See REST Payload – How to Push to Web API for detailed explanation on how to use Dotcom-Monitor to monitor RESTful APIs.
Each request will be followed by a response from the API server. The response is the data that is returned from the API in response to the request. Responses can return different data, including a JSON object.
The entire path to the resource that includes the request parameters and provides access to the resource is called a Web API endpoint. For example, the endpoint to send an API call to can look like this:
http://example.com/wp-json/wp/v2/tests
Simply put, endpoints are what we check while executing Web API monitoring calls for our web sites and applications. In general, API endpoint monitoring steps include:
- Request to an endpoint.
- Response from the API server.
- Response verification and analysis.
Benefits of Using Dotcom-Monitor as Your API Monitoring Tool
Dotcom-Monitor is a comprehensive solution that can be used for all types of Web API monitoring (see how to set up SOAP Web Services Monitoring and REST Web API Monitoring). Besides API monitoring, Dotcom-Monitor provides monitoring tools for web applications, websites, single web pages, web servers and other types of web resources.
To bring the monitoring process to a new level, Dotcom-Monitor allows users to test their target web applications in a real browser window. Browser-based testing ensures that the monitoring test is executed as close as possible to a real-life scenario and repeats real user experience. You can choose between a number of browser engines to run your application or website in including desktop and mobile browser engines.
Detailed performance reports with element-by-element waterfall charts, screenshots and video recorded while monitoring sessions give you full understanding about what exactly happens behind the scene of UI – which elements slow down your application and causes the errors and bottlenecks in its performance.
Highly-customized Dotcom-Monitor alerting system provides you with an efficient alert notification service. The system can be configured to send alert notifications to the dedicated addresses when errors are detected while monitoring. See the supported alerting mechanisms in the Alert-Delivery Mechanisms article of our Knowledge Base.