So in my previous rant YAMDS I showed you one way of going through the MDS database. The API for the MDS database is called CPMI. Its pretty crude and you can’t get to all the database but its quick and dirty.
R80 will (finally) have a real database behind it and not flat files. If we are really all good boys and girls customers they may even share the schema with us so we know where to find stuff! A very very simple MDS database will look something like this:
Now there are various ways of getting to a SQL database. Let’s compare traditional ODBC to REST
1) ODBC –
Traditional API that allows you to make SQL queries from almost any language that exist. So R80 MDS with a ODBC interface running a web server would look something like this. The web server would have a web page on it with this code:
So your web browser would connect to the MDS web server with this page http://mds/list_firewalls.php, the web server would execute this code and print out the firewalls on your web browser.
So this is a simple example. The interface could grow to others:
- http://mds/delete_all_R65_firewalls/
- http://mds/apply_licenses_to_firewalls
- http://mds/copy_policies_from_one_firewall_to_another
where the number of URLs and the complexity of the operations are infinite.
PROBLEM: Let’s say a URL blows up in the middle of some complex operation. How will that error be shown to the user? “Error NO 1234256 Abort Operation Fatal Error”. You see this often don’t you? Well its because the client PC has no visibility into the internal complexity of these URLs.
2) REST
R80 will have a new API called REST (Representational State Transfer) which allows one to query the MDS database using HTTP GET/POST/PUT/(DELETE) commands. These commands can be issued from the command line using ‘curl’ OR from your desktop web browser OR from a PHP script. So its very versatile.
These HTTP commands are a simple way to query a database:
GET: RETRIEVE a single record or multiple records
POST: CREATE a new record
PUT: UPDATE an existing record
DELETE: DELETE an existing record
and that’s it! That is REST…<wait for it>
Now for the REST of the story!!!!
OK, so there is a little bit more…the art. There is an art on how you build a REST-full interface. Pre-REST there was SOAP interface which was a huge monster pig where you could send batches of commands to a web server and it was very structured, bureaucratic and stoic – so it was probably created by the some European Union government workers. REST-full developers revolted against SOAP and tried to find the simplest, laziest way to execute a single command and depend upon the ‘community’ to behave properly instead of being enforced by gigabytes of web server code. So REST-full people are more like socialist coffee-shop dwelling dope smoking Dutch. Hence the REST-A-FARIANs (get it maaaaaan, yaaah maaaan, pass the potato chips maaaaan).
This art can start wars in the developer community “You aren’t REST-full!”, “Yes I am a REST-A-FARIAN!!!!”. So it will be interesting to see if the R80 is REST-full or not…which of course will be subjective depending on which cultural attitude you aspire to.
But these are the basics I gleamed from a cloud smart friend of mine Steve Morman who does cloud stuff running weather web sites.
With REST you have:
- Resources: Full URL that points to data in a table in a database (e.g. http://mds/network-objects)
- Verbs: Actions to take on these tables (GET/CREATE/UPDATE/DELETE). Notice these are the ONLY 4 actions. You won’t see an action like http://mds/apply_rules_then_delete_objects_then push_policy_then_drink_your_milk.php
- Nouns: The data which is structured more on how the database tables are laid out:
- http://mds/rule,
- http://mds/license;
- http://mds/network-object
- Parameters to query for filtering data (e.g go through network objects filtering on clusters)
http://mds/network-objects?type=gateway_cluster
- Options: MIME header of HTTP request. (e.g. how you’d like to see the format of the return data json or xml)
Example of generic HTTP header the tells the server how it would like to see the data formated
So here is how it all works together (bit simplified)
- CREATE a new object
http://mds/network-object
POST /network-object HTTP / 1.1
name=fw1&type=gateway;ip=1.1.1.1&interfaces=3&…………..
- The POST returns a RESOURCE ID: 74859. This number is used to refer back to the record in the database. This is the glue that ties the client into the database to get records back out.
- RETRIEVE the same object
http://mds/network-object?resource-id=74859 will get the record back
Now are you ready for the art?
Each application interface will describe what good and bad queries look like. Check this out:
https://github.com/WhiteHouse/api-standards
If one specifies http://mds/network-object you will get a single object back because it is singular. If one specifies http://mds/network-objects (plural ‘s’) you will get the whole table back. That is the ‘art’ in defining how these URLs are to be used.
….and that’s all I got. Simple huh?
The Win?
- Simple interface into a database
- Can use variety of applications from command line to web browser to access the database
- If there are errors in processing it will be on client side, so better chance you get a decent error from it
- You don’t need 1000 URLs on the server to do all types of complex processing. You can still have them, but not required
- Processing offloaded from server so theoretically can handle more clients
- Cleaner, easier to understand for even the common man like myself
Summary
REST will make R80 a true enterprise class management server. Any type of management server must be able to import/export data so it can integrate with the rest of the environment using automated scripts. While I love cpmiquerybin, its days are coming to a end.
All Hail REST!
dreez
Many Thanks to Steve Mormon who laid to REST the concepts so simple that even bald old guys like me can understand.
Steve was babysitting his beautiful wife Arah (our climbing partner) who likes to fall down on ice while trail running.
DreezSecurityBlog 