Wednesday, March 18th, 2009
I used to use soapUI back when I was creating a SOAP API for a national wireless carrier. Thankfully, I’ve been working primarily with REST APIs since then. I noticed that soapUI had added REST support to their product, and recently I decided to try it out.
The REST API that I’m developing is in Rails (this is my first foray into Rails; I’m usually a Java guy with some occasional dabbling in Django and Grails), so the URLs don’t follow the traditional query-string format for passing parameters. E.g., instead of GETting http://server:port/resource?id=123 to retrieve the resource with ID 123, it’s http://server:port/resource/123.
For some reason (admittedly, I was being pretty dense at the time), it took me a long time to figure out how to do this in soapUI, but if you’ve stumbled into my blog by Googling for how it’s done, here’s the trick: first, set your resource URL to /resource/{id} (note that id is in curly braces). Then, when defining your parameters, instead of leaving the STYLE parameter at its default value of QUERY, set it to TEMPLATE, being careful to name your parameter as it is named in the resource URL (in this case, id). When soapUI generates the request, it’ll replace the {id} with the parameter’s value.
Tags: rails, REST, soapUI
Posted in blog | Comments Off
Tuesday, April 24th, 2007
I’ve been reading and thinking a lot about REST lately. There’s a good high-level intro to REST here, here, and (of course) here. I suppose part of my interest in it stems from my recent projects at work. I was part of a team that exposed a bunch of our product’s functionality as a brand-new SOAP API. What struck me was how complicated it all is. It’s supposed to be a simple way to use standardized formats to enable an RPCs across and among disparate technologies, and for the most part, it delivers (Idiosyncrasies like getting a .Net SOAP client to pass dates to a Java SOAP servers, and vice versa, in different timezones, with null dates, notwithstanding). But the steps involved in creating the service, exposing it, generating the WSDL, embedding that WSDL in the deployed war file, then getting the clients to generate stubs from those WSDLs and making it all work… well, it’s cumbersome. More cumbersome than it oughtta be. Full disclosure – my only exposure to creating SOAP web services is through Apache Axis. I’ve heard that CodeHaus’s XFire and even .Net are easier to work with.
So reading about RESTful services was like a breath of fresh air. Now, every article I’ve ever read says that REST does not necessarily need to use HTTP as its transport protocol, but then they invariably proceed to discuss how HTTP’s GET, POST, PUT, and DELETE commands map really nicely to the ubiquitous CRUD database operations, and explain how to implement REST on HTTP. But I wonder if it wouldn’t make just as much sense to implement a RESTful service on FTP. Why not? The “resources” in both cases are basically file pointers. You could do get, put, and delete, and navigate through the hierarchy of resources with cwd. For transferring large files, the FTP protocol might actually be better suited for the task. So, e.g., let’s say you have a DSS application where you’re transferring large batches of data to a data warehouse from an OLTP database. Why wouldn’t this be a perfect situation for creating a RESTful service over FTP?
Tags: REST
Posted in blog | Comments Off
