REST in IIS
Trying to do REST on IIS using ASP.NET, with some success so far.
The task is to create a shared storage area for scanning jobs.I started out with a set of types, in Haskell notation:
CreateJob :: IO (Status, Location) UploadFile :: Job ID -> File -> IO (Status, Location) ModifyFile :: Job ID -> File ID -> File -> IO Status RetrieveFile :: Job ID -> File ID -> IO (Status, File) DeleteFile :: Job ID -> File ID -> IO Status ListFiles :: Job ID -> IO (Status, [Location]) ListJobs :: IO (Status, [Location]) DeleteJob :: Job ID -> IO Status
The IO tag tells us that the value is created by some I/O operation on the server, but not much else – it’s not obvious which functions are idempotent, and which aren’t, for instance. It strikes me that a proper Haskell DSEL for REST notation could capture that information, and much else besides. But then, before you knew it, you’d be writing your web applications in Haskell.
Anyway, manually translating the above into HTTP requests addressed to URLs, it breaks down fairly cleanly into the following:
- CreateJob
- POST to /, (successful) status=201, location=/JobId
- UploadFile
- POST File to /Job_ID, status=201, location= /Job_ID/File_ID
- Modify File
- PUT File to /Job_ID/File_ID, status=204
- Retrieve File
- GET to /Job_ID/File_ID, status=200, content=File
- Delete File
- DELETE to /Job_ID/File_ID, status=204
- List Files
- GET to /Job_ID, status=200
- Delete Job
- DELETE to /Job_ID, status=204
The next task was to get the URL rewriting working. I decided to use a custom IHttpHandler (very much like a Resource in ), and ensure that it was called by appending /handler.aspx to every URL.
That’s pretty much all there is to it, apart from writing the actual code to perform the requested operations on the server. Because it’s on IIS, we can use Windows authentication for security (yes, yes, I know…quit smirking…). I’ve heard it said that you can use WSDL to describe RESTful web services, but I don’t wanna. Something like the Haskell notation alluded to above would be much cooler.
The lists of URLs returned by ListJobs and ListFiles are formatted as plaintext separated by newlines. (I was originally going to use RDF lists encoded in RDF/XML, but none of the arguments I came up with for which this was better seemed terribly convincing to me).
November 4th, 2004 at 12:09 pm
All your file operations are beginning to look like WebDAV :)
November 4th, 2004 at 12:21 pm
Well, yes. It is like a subset of WebDAV (without the additional HTTP verbs).
The main difference is that job and file IDs are allocated by the server (whereas with MKCOL you tell the server what URL you want for your collection). The point is to ensure that CreateJob creates a new, unique URL, and for the client not to have to keep track of what URLs have been used before.
November 4th, 2004 at 2:20 pm
This bit is interesting:
POST File to /Job_ID, status=201, location= /Job_ID/File_ID
Amazing HTTP has a Created status code, and redirects you to the new resources. Not something you see used every day by web browsers.
November 4th, 2004 at 2:37 pm
There is a kind of sweet spot where you can get a set of RESTful web services to double up as a browsable user interface, for instance by translating XML-formatted server responses into HTML with XSLT. On the other hand, there are things HTTP can do that most browsers don’t do (like POST raw binary data or an XML document instead of a set of form fields).
Of course that’s changing now, as web applications like GMail start talking directly to servers from inside the browser, updating the contents of the page via scripting instead of having to refresh the complete page (or a frame) every time something changes.
I wonder what percentage of web developers are aware of the difference between POST and PUT?
October 4th, 2006 at 9:35 pm
[...] REST in IIS [...]