Semantic Techniques to Support IoT Interoperability
235
4 The API Analysis
Analysing the API exposed by sensors’ vendors is not only the first, but also the
most delicate step. Indeed, understanding how the APIs can be called, through the
accepted input parameters, and interpret the results of the call by reading the output,
can be quite complicated when it comes to automatically doing it. Sensors’ input
parameters and output responses are generally described either in Json (which is the
most common representation) or XML. In both cases, such parameters are very well
structured, but such a structure varies greatly when comparing different providers.
Also, most of the modern APIs are represented by REST calls. Starting with these
assumptions, we are experimenting with three different possible approaches:
1. A completely automatic analysis of the REST APIs, obtained via commercial or
open-source tools, such as IBM Appscan Security, ZAP and SoapUI. Such tools
generally address security and quality of service issues, by analyzing the input
parameters accepted by a REST call and the returned output.
2. The exploitation of text parsers, which can analyze the online documentation
provided by manufacturers and identify the description of input and output
parameters. This kind of approach requires the application of natural language
processing (NLP) techniques, which are not always reliable, especially when the
structure and semantics of the documentation vary from a source to another.
3. A completely manual analysis of the API and population of the API ontology.
This is the most effective approach, as the possibility to make errors and create
ambiguities is extremely reduced (provide that the human operator is skilled
enough to understand the sensors’ descriptions). However, it is highly inefficient,
as such analysis would require time, and would also be impractical for frequent
updates of the sensors’ description.
Considering the practical difficulties of applying only one of the three approaches, we
have considered a combination thereof: a human operator always acts as a supervisor
for the automatic analysis obtained via REST tools and web parsers, solving ambiguities and possible misinterpretations. However, once the API ontology description
has been consolidated, automatic tools are able to operate almost independently, as
the possibility to introduce errors is reduced dramatically with a stable ontology. So,
eventual updates of the API can be handled by automatic analysis tools, with sporadic
intervention from a human operator required. In order to start the analysis of an API,
the user can use the main control panel of the proposed tool, shown in Fig. 2. There
are two main options available: the user can import existing services definitions (she
has already analyzed an API before) or start a new analysis. In the first case, after
the import, the user will be presented with a set of Services, which she can then
select to proceed with the semantic annotation, as shown in Fig. 3. Otherwise, she
will be asked to insert the URL of the sensor’s REST service and she will be asked to
choose the input parameters (which will be automatically retrieved) to use to probe
the service and analyze the output.
235
4 The API Analysis
Analysing the API exposed by sensors’ vendors is not only the first, but also the
most delicate step. Indeed, understanding how the APIs can be called, through the
accepted input parameters, and interpret the results of the call by reading the output,
can be quite complicated when it comes to automatically doing it. Sensors’ input
parameters and output responses are generally described either in Json (which is the
most common representation) or XML. In both cases, such parameters are very well
structured, but such a structure varies greatly when comparing different providers.
Also, most of the modern APIs are represented by REST calls. Starting with these
assumptions, we are experimenting with three different possible approaches:
1. A completely automatic analysis of the REST APIs, obtained via commercial or
open-source tools, such as IBM Appscan Security, ZAP and SoapUI. Such tools
generally address security and quality of service issues, by analyzing the input
parameters accepted by a REST call and the returned output.
2. The exploitation of text parsers, which can analyze the online documentation
provided by manufacturers and identify the description of input and output
parameters. This kind of approach requires the application of natural language
processing (NLP) techniques, which are not always reliable, especially when the
structure and semantics of the documentation vary from a source to another.
3. A completely manual analysis of the API and population of the API ontology.
This is the most effective approach, as the possibility to make errors and create
ambiguities is extremely reduced (provide that the human operator is skilled
enough to understand the sensors’ descriptions). However, it is highly inefficient,
as such analysis would require time, and would also be impractical for frequent
updates of the sensors’ description.
Considering the practical difficulties of applying only one of the three approaches, we
have considered a combination thereof: a human operator always acts as a supervisor
for the automatic analysis obtained via REST tools and web parsers, solving ambiguities and possible misinterpretations. However, once the API ontology description
has been consolidated, automatic tools are able to operate almost independently, as
the possibility to introduce errors is reduced dramatically with a stable ontology. So,
eventual updates of the API can be handled by automatic analysis tools, with sporadic
intervention from a human operator required. In order to start the analysis of an API,
the user can use the main control panel of the proposed tool, shown in Fig. 2. There
are two main options available: the user can import existing services definitions (she
has already analyzed an API before) or start a new analysis. In the first case, after
the import, the user will be presented with a set of Services, which she can then
select to proceed with the semantic annotation, as shown in Fig. 3. Otherwise, she
will be asked to insert the URL of the sensor’s REST service and she will be asked to
choose the input parameters (which will be automatically retrieved) to use to probe
the service and analyze the output.