Сохранено: RESTful SNMP Over HTTP. Part 4 / Marco Bresciani · Mar. 17, 17

[r3code]

Часть 1, часть 2, часть 3, часть 4.
Part IV
Commercial value allows you to uniquely map the entirety of SNMP operations and MIB data structures to HTTP protocol and URIs.
Let's see how we can possibly use everything we've read until now, with some additional RESTful views of similar behaviors, possible implementations, and further ideas.
Commercial Value

Let's take a look at the value, benefits, and more of commercial value.


Value and Benefits

The invention allows us to uniquely map the whole SNMP operations and MIB data structure to HTTP protocol and URIs, providing a more modern way to present such data structure and introducing the concept of uniform interface, allowing the data system (or the network device) to produce a uniform content regardless the type of the user by focusing only on the actual request format and content.

This solution allows implementing one single unique system that does not need to have custom implementations and interactions based on the user or software type that it is interacting with. The solution proposed, instead, is a uniform and unique interface that focuses its attention on the received URIs only, together with HTTP protocol header details, in order to comply with such requests and to produce one answer that fits all needs (or, more specifically, an answer that fits the specific request by the user).

Instead of producing one SNMP interface, one set of web services with related WSDLs, and one complex web-based (or desktop-based) GUI, the solution allows the product to be released with only the SNMP specification. The rules can translate the MIB into URIs (depicted by this solution) and a general-purpose, even third-party, simple software that is RESTful aware and can send general purpose HTTP request as per user customizations (i.e., one REST client plugin for Mozilla Firefox is about 100kB, while a MIB browser software application is at least one magnitude order bigger).
Likelihood of Use

Regardless the technology through which this solution is implemented, providing this kind of unique interface for all interactions (either human- or software-based) allows network devices internal software to be smaller and simpler, needing to fulfill single specific requests without any need to know the details of the interacting party. It’s then reasonable that other may introduce this idea and solution in other products in order to simplify their implementation, the embedded web-based software and the interactions between the user, and the internal set of data - thus reducing the number of bugs, the need for custom and specific user interfaces with a complex user experience, and so on.
How to Identify

Since the mapping rule is clear and well-defined, it should be very easy to identify an OID from an HTTP(S) request (or response) URI, giving us very easy visibility for the invention. Since the usage mechanisms depend on the mapping and all the other options described, the mapping itself and its rules should also be described in the product documentation for user needs.
How to Design Around

This solution is very broad. It is easy to design extensions, enhancements, and different usages around it since REST and RESTful ROAs are wide and general-purpose concepts that easily scale and extend.

It is easy to understand how, for example, this idea could become a method to manage file systems through an HTTP RESTful interface. Files in a network device, but not necessarily only those, may use this solution and idea. Using the URIs to map file system tree and its directories and files, this idea can work as a RESTful HTTP-based FTP protocol.

Replacing FTP-specific commands with uniform URIs (such as URI_ROOT/usr/lib/cups/gutenprint.5.2) means that the uniform interface may easily interact with those file via HTTP methods.

Specifically, the GET method will retrieve files content when operating on a file, whereas it will retrieve directories listing when operating on a directory (URI_ROOT/usr/lib/cups/ in the example URI above). To retrieve information on files or directories even before GETting them, the HEAD method, as per its definition, is the proper solution.

The PUT method will instead be used to create a file (or a directory), as before, listing the filename in the URI exactly as above but using the PUT method and filling the HTTP entity-body with the file content, or, for example, leaving it empty to create a directory.

Again, to both delete a directory or a file with no differences, it is possible to use the DELETE method of HTTP protocol. At the same time, HTTPS for security and access permissions management allows authentication and authorization procedures.

So, with respect to FTP, there is no need for changing directory to ask for binary or ASCII format or other peculiarities. But the uniform RESTful HTTP interface easily maps a whole file system to URIs also providing operations for working on those files (retrieve from, add, and delete to the file system).

It is easy to write ftp://user@example.org/my/own/file.txt to retrieve a file through FTP from any Internet browser (but it is generally not possible to use sftp:// from the same browser since the protocol is unsupported).

It is also possible reading a directory listing or adding or deleting a file, but these operations generally need specific clients or permissions and there is no one common way to do all operations. Having the HTTP protocol DELETE and PUT methods allows simple usage of any kind of networking API for HTTP or RESTful client to send data to a specific URI. These data will become a file in the file system.

To further merge this idea with the RESTful SNMP mapping described above by simply attaching a mib/ string to the idea above, everything works perfectly with the MIB itself as a whole becoming a resource (/mib) with its transactions (/mib/t or simply /t). Everything else can do the same, so the URI that maps the /files resource may represent resources that are directories and files inside the network device and its file system. This kind of mapping extension may replace FTP (File Transfer Protocol).

Another extension, following the same concept, is the possibility to use the uniform interface and REST guidelines to map network device’s operating system commands generally used through Telnet or SSH. It requires care to carefully design each resource or command with its parameters, keeping the basic concept of the uniform interface usage without breaking the basic rules. Again, it is also possible merging internal commands with the ideas with the URI/commands or /c and so on.

Speaking of actual implementations, it is reasonable (and probably mandatory!) to define and implement an automatic translation process converting actual MIB files to a set of proper configuration files for the software architecture so that URI mapping and resources interactions will be automatically mapped onto the application server depending on the MIB definition, leaving out all manual heavily error-prone conversion steps.

A plausible implementation that would help the ROA architect fulfil MIB specification, resources and users profiles: defining a general purpose framework able to receive the whole MIB (ASN.1) specification files as input, together with the set of user profiles and another set of configuration file (either YAML, XML, …) that maps user profiles permissions on each single resource.

Such a framework would take care of these inputs and should be able to provide a predefined scaffolding environment (a web application) that can reply to HTTP(S) requests according to MIB resources and user profiles and permissions. Since the inputs are static and standard and the behaviors are actually clear and predefined, this implementation should not be theoretically complex, assuming that the developers will define specific file formats for user profiles and resources/user permissions mapping.

There are frameworks already able to create data models, DB updates, GUI web pages and simple controllers starting from few data type definitions (see here for simple examples), so creating such automated environment should be the first step to defining a general implementation for the solution described here.

Smarter and better approaches for requests and responses formats may easily involve ontologies and semantic web, defining the MIB structure, data types, and objects relations through, for example, RDF (Resource Description Framework) or HTML5+RDFa that can be easily transformed via XSL(T) applications for better human or automatic parsing and management. A theoretical, brief, example structure of a URI_ROOT/1/3/6/1/2/1/1/1.en.html request may result in something like:

http://www.w3.org/1999/02/22-rdf-syntax-ns#" lang="en">