RESTing for a moment...

Yeah, easy play on words, but I like it...

It has been awhile I have written anything. Lately, I got to training on mySQL (more on that later!) and it was a very good training. At one point, in a discussion between a friend and I, I got to the realization that, "wouldn't it be nice to have a simple URL based API to administer MySQL?" I know you can find stuff about that on the web right now (like this on php) but I didn't find anything with JEE. But for us, the added spark was to be able to notify the administrator when something happened, using SMS. So, "the system" would monitor the mysql "key points" and notify who is interested in what happened through SMS. If this is interesting to you, well, read on...

Well, what do you know, using the REST approach with Jersey, and a very informative tech tip, made the REST part so simple, it is (almost) not fun anymore... So, here is a few things I have though of doing, and what I have learned about Jersey, as I am still in the REST learning curve, this is not complete by any means. But I'll get back to update this entry when I learn new stuff about this.

Ok, some ground rules here...

• REST is about using the http methods (GET, PUT, DELETE)
• REST URLs are kept deceptively simple, hence, minimize the parameter usages. The information is encoded in the URL.
• The REST Resources are bounded to a base URL (using the Jersey annotation model)
• Resources come in two shapes. Base resources, and sub-resources.
• Any sub-resource has to be instantiated from a base resource.

For example...

Using the idea of accessing mySQL with a REST interface, the first thing we can do is to get the list of the schemas, so a url like:

• http://localhost:8080/mySQLRest/resources/schemas instead of
• http://localhost:8080/mySQLRest/mySQL?cmd=listSchema

Makes it easier to read. While in this one, the difference is that much, it is clearer in the following sample for a table describe:

• http://localhost:8080/mySQLRest/resources/schemas/desc/myworld/cityview or
• http://localhost:8080/mySQLRest/mySQL?cmd=desc&schema=myworld&table=cityview

The exact sentence can be discussed ad nauseam, but you get the idea... The structure I used for the rest interface is:

<base url>/area/<command/<variables>

1. area in [admin, schemas]
2. in admin, commands are in [ping, processList, variables, status, kill, extended-status]
3. in schemas, commands are in [desc, select, delete, update, create]

I'll see how far that will take me. Bear in mind that this is not meant to be a full fledge re implementation of the mySQL API, but just what I need to get by. The whole idea for me, is to be able to do minimal admin tasks with this, but mostly, register for state change in mySQL, and to notify the administrator (do you see IEP creeping in? :o) )

To get notified of events, you first need to register. Here is the REST URL for the registration:

• http://localhost:8080/mySQLRest/resources/registrations/sms/<yourphone>/dbdown (if the db is not reachable)
• http://localhost:8080/mySQLRest/resources/registrations/sms/<yourphone>/ping (if you want to know every time a ping is sent).

Nowadays, most IT professionals have email on their cell phones. So, for them, the notification could be sent to an email address. But some people, like me, prefer to decouple that function in a PDA and have a cheaper cell phone. But even basic cell phones have some level of browsing capability. So being able to use the REST format for the registration, make is easier on a small device, or even in a midlet, to send the request (no need for SOAP support). In any events, with the SMS being sent out, even I can be reached, most of the times...

A few "REST things" learned...

(Yes, I am a sucker for bad punts...)

When creating the annotations...

@path("admin"), @path("/admin") and @path("/admin/") seems to be giving the same behavior.

If you need to do multi-level resource nesting...

@path("{method}/{endpoint}/{eventName}") is to be placed in the base resource, and not nested in a chain of sub resources.

When delegating to a sub resource...

Pass in the context to the sub resource's constructor, especially if you intent to use query parameters (the elements after the "?" in http:/server/app?X=1&Y=2) in the sub resource.

When to use REST and when to use WSDL?

I can't touch REST without trying to compare it to a SOAP based protocol. Here is a few things that I got the impression of. Bear in mind, I'm only starting to use REST....

• REST is faster to develop in
  • WSDL is more stable (requires a more precise contacts on the communication)
• REST is simpler to develop in
  • WSDL is more complex to start with, but you can keep more complex systems manageable
• REST can be easily used on small devices (cell phones, set to boxes)
  • WSDL requires SOAP support to be available, but small devices are more powerful with each passing year.
• WSDL is extendible
  • Ok, to me, there is nothing REST can do about this one. REST has to rely on HTTP for any additional capability, where as WSDL can be extended, augmented by interceptors that can process the headers and other information.
• REST does not require an XML format
  • This can be useful (for JSON communication for example) but it can also be a downfall. Requiring XML makes it easier to deal with multiple systems.

So, when to use one or the other? The decision is definitely based on the project you're doing and the environment you're developing in. For independent projects or grass root projects, REST is definitely a good candidate. For reuse, WSDL has definite advantages. But in the long run, both are here to stay because they respond to different basic needs.

So, what about the REST of the notification system?

In this blog, we have covered an introduction to using REST and the API I am building for the MySQL admin notification, the remainder of the system will be the target of other blogs. The total system will have:

1. REST Registration Interface
2. MySQL Monitoring
3. BPEL triggered for the monitoring of the event, if necessary
4. Event notification broadcast

Next stop, the MySQL Monitoring...

Posted at 11:30AM Jun 12, 2008 by sergeblais in MySQL  |  Comments[0]