I was just reading a page on RESTWiki about HowSoapComparesToRest. Despite the title, about half the page is devoted to a discussion of what the State in REpresentational State Transfer is.
Reading through that discussion and seeing people trying to get a handle on what resource's state is transferred when you do a POST to certain kinds of resources or the fact that you might transfer the state of a resource that has no name, I suddenly had the thought that its not so important to know what state is -- its what it's not that's important. In fact, its really not so much about the state at all -- its about the representation. In a RESTful system, (in a very general sense) you dont move objects (resources) around, you move facsimiles (representations) of those objects (resources) around.
Why is this important? I'm not sure I know at this point. I just know that after several years of thinking and reading about REST, this is the first time I've thought about it this way.
20 April 2005
04 April 2005
REST v WS-*: Compare and contrast
I've been spending a lot of time looking for information that compares and/or contrasts WS-* with REST. As I go, I've been accumulating links here and there, saving them in various places (bookmarks in my browser, on the desktop, and at bloglines), but this weekend, I decided that it was about time I got with the program and availed myself of the services offered at del.icio.us. Once I'd gotten an account set up and had moved over all my bookmarks I had lying around in varoius places, I spent a good deal of time Sunday perusing a few email threads over on the ws-arch mail archives and a few more over in the xml-dev archives.
As I find things that appear to be of the REST vs. WS-* ilk, I'll add them to the restvsoap tag that I set up on del.icio.us. I'm hoping that at least a few other people notice the tag and are able to add some useful pointers as well. I'll try to limit myself to using the restvsoap tag only for things that have useful comparisons rather than just being flame-fests; hopefully others will do the same.
As I find things that appear to be of the REST vs. WS-* ilk, I'll add them to the restvsoap tag that I set up on del.icio.us. I'm hoping that at least a few other people notice the tag and are able to add some useful pointers as well. I'll try to limit myself to using the restvsoap tag only for things that have useful comparisons rather than just being flame-fests; hopefully others will do the same.
28 March 2005
Parallel Universe
I've reached the chapter that talks about WS-Addressing and the WS-Resource Framework (chapter 8 in Building Web Services with Java). Apart from having a hard time getting my ahead around the authors' concepts of stateful and stateless resources, I couldn't help but feel like I was traveling through a parallel universe. I was left with the impression that the whole WS-Resource framework is an attempt to duplicate what we already have in the existing web - but crammed inside of the WS-* world and using none of the existing mechanics already available. It's as if their charter was to reinvent the web without using any of the existing technologies - and to make sure it doesnt interoperate with the existing web.
I've also noticed that as I've been reading I keep finding myself wishing that some of the things in WS-* could be extracted and applied to a more RESTful environment. In particular, I keep wondering whether having something like WSDL would be useful.
Let's say that I have a real estate 'application' that deals with real estate listings. A listing resource has state that includes things like an address, a listing agent, a homeowner, a description, a listing status and a unique identifier. In order for client software to effectively use my 'application', I need to be able to define how the client can interact with resources of this type (e.g., listing resources). It seems to me that in order to construct a client that can interact with a particular type of resource, I need to know the following things:
I'm pretty sure that the first and last items are reasonable things to want. Its the middle one that I'm not so sure of. I can't help but think that I'm effectively trying to define new operations that can be performed on a resource, and that would seem to violate the constrained interface.
I did look at RDF Forms, but I'm not sure whether that's what I want or not. It seems like something is missing, but maybe I'm just making it more complicated than it needs to be
I've also noticed that as I've been reading I keep finding myself wishing that some of the things in WS-* could be extracted and applied to a more RESTful environment. In particular, I keep wondering whether having something like WSDL would be useful.
Let's say that I have a real estate 'application' that deals with real estate listings. A listing resource has state that includes things like an address, a listing agent, a homeowner, a description, a listing status and a unique identifier. In order for client software to effectively use my 'application', I need to be able to define how the client can interact with resources of this type (e.g., listing resources). It seems to me that in order to construct a client that can interact with a particular type of resource, I need to know the following things:
- the resource's state or data model; i.e., what elements make up a listing resource's state (I guess this would essentially be a type definition)
- a list of valid transformations that can be applied to a listing resource; i.e., what parts of the resource's state can I change, and how do I go about effecting those changes
- a definition of valid values for the various parts of the resource's state (maybe this is really part of the data model)
I'm pretty sure that the first and last items are reasonable things to want. Its the middle one that I'm not so sure of. I can't help but think that I'm effectively trying to define new operations that can be performed on a resource, and that would seem to violate the constrained interface.
I did look at RDF Forms, but I'm not sure whether that's what I want or not. It seems like something is missing, but maybe I'm just making it more complicated than it needs to be
25 March 2005
SOAP Transport Independence
More thoughts while reading...
I keep thinking about SOAP's use of HTTP as a transport protocol and the fact that SOAP is supposed to be transport independent so you can make use of existing protocols like SMTP or FTP or whatever. I gues my question at this point is why?
Why would I want to use SMTP instead of HTTP? What does that buy me? OK, so I dont need a web server to service requests - I can just float stuff through email. But now I need to write some new sort of server that can poll the service's 'inbox' and process the messages that it finds there. So not only do I still need some sort of server, but now I've got to write my own when I could have just used already existing and readily available web server software.
As to the question of why HTTP is the preferred protocol, I suppose I can see why that's the case. There's already lots of well tested HTTP client and server software out there, so its real easy to use. And just about everybody lets HTTP through the firewall. But isn't that really just a port number? I could run any protocol on port 80 and it would still make it through just about as many firewalls.
Well, back to reading. Maybe the answers will eventually become clear to me, but it just feels like the whole protocol independence thing and the use of HTTP has made things much more complicated than they need to be.
I keep thinking about SOAP's use of HTTP as a transport protocol and the fact that SOAP is supposed to be transport independent so you can make use of existing protocols like SMTP or FTP or whatever. I gues my question at this point is why?
Why would I want to use SMTP instead of HTTP? What does that buy me? OK, so I dont need a web server to service requests - I can just float stuff through email. But now I need to write some new sort of server that can poll the service's 'inbox' and process the messages that it finds there. So not only do I still need some sort of server, but now I've got to write my own when I could have just used already existing and readily available web server software.
As to the question of why HTTP is the preferred protocol, I suppose I can see why that's the case. There's already lots of well tested HTTP client and server software out there, so its real easy to use. And just about everybody lets HTTP through the firewall. But isn't that really just a port number? I could run any protocol on port 80 and it would still make it through just about as many firewalls.
Well, back to reading. Maybe the answers will eventually become clear to me, but it just feels like the whole protocol independence thing and the use of HTTP has made things much more complicated than they need to be.
SOAP. SOAP. What is SOAP?
Since I've got some free time on my hands (while I look for a new job), I decided it'd be a good idea to get caught up on current technology - and first up is SOAP/SOA/WS-*, etc.
I've actually used SOAP and Axis on a couple of projects now, but only in a sort of peripheral manner. In fact, in both cases, the presence of a web service interface was more related to marketing than actual customer demand (you know - "let's put a web service interface on so we can say our product supports SOAP"). And since the web services part wasn't part of the core architecture, I've never spent much time really investigating and trying to understand the why's and wherefore's of SOAP and Web Services.
So, last week, I went out and picked up the dead tree version of Building Web Services with Java. (I had hoped to find something on O'Reilly's Safari Bookshelf since I do have a subscription, but it seemed like everything there was at least two years old.)
Berfore I go on, I should point out that I've been a pretty strong believer in the REST architectural style and, over the past three or four years, I've made a pretty concerted effort to adhere to those principles in the solutions I've designed and built. I'm very much aware that there's a sort of SOAP/WS-* vs REST mentality out there right now, but I really dont know enough about SOAP and WS-* to know where I might fall in that debate. At this point, from what I've read so far I have what you might call a healthy skepticism for SOAP and WS-*.
So far, and for the most part, I like the book. Despite the fact that the authors seem to think Web Services are the greatest thing since sliced bread, they do manage to take you through all the pieces that are involved - XML, SOAP, Web Services - and they bring up just enough of the issues that Web Services are trying to address to make you think a little bit. There are a few sidebars that compare to REST and WS-*, but they're pretty superficial and it seems like they're only there to make the presentation look balanced.
So far, there haven't been any surprises. I've either heard of or have actually used most of the technologies they've covered - XML and XML Schema, SOAP, WSDL, UDDI, Axis, etc. However, I can't help but to keep asking myself "What happened to the web in Web Services?"
Two things strike me. One is that, despite the use of URIs for just about everything that needs a name, almost none of them actually identify a resource that's on the web. The only thing that even comes close is the service endpoint, and that's barely on the web since all of the useful stuff is hidden behind the service.
The other thing that bugs me is the use of HTTP is a transport protocol. Other than the fact that HTTP flows freely through firewalls, what's the point? Only one verb, POST, is ever used (although I do see that you can now do certain operations using GET as well). I keep asking myself why they didn't just come up with the SOAP Message Transfer Protocol. Well, OK, the acronym for that might cause just a little confusion, but still. Maybe I just need to read more and I'll understand.
(In case you're wondering, the title is a reference to a bit from a Sponge Bob Squarepants episode.)
I've actually used SOAP and Axis on a couple of projects now, but only in a sort of peripheral manner. In fact, in both cases, the presence of a web service interface was more related to marketing than actual customer demand (you know - "let's put a web service interface on so we can say our product supports SOAP"). And since the web services part wasn't part of the core architecture, I've never spent much time really investigating and trying to understand the why's and wherefore's of SOAP and Web Services.
So, last week, I went out and picked up the dead tree version of Building Web Services with Java. (I had hoped to find something on O'Reilly's Safari Bookshelf since I do have a subscription, but it seemed like everything there was at least two years old.)
Berfore I go on, I should point out that I've been a pretty strong believer in the REST architectural style and, over the past three or four years, I've made a pretty concerted effort to adhere to those principles in the solutions I've designed and built. I'm very much aware that there's a sort of SOAP/WS-* vs REST mentality out there right now, but I really dont know enough about SOAP and WS-* to know where I might fall in that debate. At this point, from what I've read so far I have what you might call a healthy skepticism for SOAP and WS-*.
So far, and for the most part, I like the book. Despite the fact that the authors seem to think Web Services are the greatest thing since sliced bread, they do manage to take you through all the pieces that are involved - XML, SOAP, Web Services - and they bring up just enough of the issues that Web Services are trying to address to make you think a little bit. There are a few sidebars that compare to REST and WS-*, but they're pretty superficial and it seems like they're only there to make the presentation look balanced.
So far, there haven't been any surprises. I've either heard of or have actually used most of the technologies they've covered - XML and XML Schema, SOAP, WSDL, UDDI, Axis, etc. However, I can't help but to keep asking myself "What happened to the web in Web Services?"
Two things strike me. One is that, despite the use of URIs for just about everything that needs a name, almost none of them actually identify a resource that's on the web. The only thing that even comes close is the service endpoint, and that's barely on the web since all of the useful stuff is hidden behind the service.
The other thing that bugs me is the use of HTTP is a transport protocol. Other than the fact that HTTP flows freely through firewalls, what's the point? Only one verb, POST, is ever used (although I do see that you can now do certain operations using GET as well). I keep asking myself why they didn't just come up with the SOAP Message Transfer Protocol. Well, OK, the acronym for that might cause just a little confusion, but still. Maybe I just need to read more and I'll understand.
(In case you're wondering, the title is a reference to a bit from a Sponge Bob Squarepants episode.)
22 March 2005
Hello
So, I've finally set up my own blog. (Cue sound of crickets chirping.)
I've been thinking about doing this for a while, but I've never really been motivated enough to actually do anything. I've come real close a number of times over the past few months, but each time I've been thwarted by my inability to come up with a name that I like (seems I struggle with naming even outside the software world). So today, in an effort to avoid doing something else that I really should be doing, I managed to come up with a name and finally get myself my very own blog.
Why
So why am I doing this? I'm not completely sure. I've thought of any number of reasons why I should do a blog, but in the end, I think there are only two that really matter.
Writing Practice
I've never been very happy with my writing skills. For one thing, my mastery of grammar and punctuation leaves more than a little to be desired - I really wish I'd paid much more attention in my high school English classes. But that's minor stuff. What really bugs me is the fact that I always seem to have so much trouble getting the thoughts in my head into words on the screen. It's not that I sit and stare at the screen with writer's block - I can generate plenty of words. The problem is coming up with the right words and getting them in the right order so that when someone else reads what I've written, they have half of chance of understanding what I'm trying to say.
I suppose I could take a writing class - and I might well do that eventually, but it seems like the simpler thing to do is to just start writing more. Practice makes perfect and all that.
Seeing What Happens
Beyond the writing practice, the only other reason for doing this blog is to see what happens. I dont necessarily think I have a whole lot to say. I don't consider myself exceptionally smart, nor do I think I'm a deep thinker. And I'm certainly not an expert on anything in particular (I'm more a jack-of-all-trades kind of guy). But that doesnt seem to stop most people. And I'm not going to let it stop me either.
Maybe, if I'm really lucky, I'll manage to start a conversation or two of my own and actually get some feedback. Maybe I'll find out that I'm pretty normal and that my approach to doing software fits in with the way most other people do it. Or, maybe I'll find out that I'm way out in left field making mountains out of molehills and my writing really does suck as bad as I think it does. Either way is fine by me - at least I've learned something.
I've been thinking about doing this for a while, but I've never really been motivated enough to actually do anything. I've come real close a number of times over the past few months, but each time I've been thwarted by my inability to come up with a name that I like (seems I struggle with naming even outside the software world). So today, in an effort to avoid doing something else that I really should be doing, I managed to come up with a name and finally get myself my very own blog.
Why
So why am I doing this? I'm not completely sure. I've thought of any number of reasons why I should do a blog, but in the end, I think there are only two that really matter.
Writing Practice
I've never been very happy with my writing skills. For one thing, my mastery of grammar and punctuation leaves more than a little to be desired - I really wish I'd paid much more attention in my high school English classes. But that's minor stuff. What really bugs me is the fact that I always seem to have so much trouble getting the thoughts in my head into words on the screen. It's not that I sit and stare at the screen with writer's block - I can generate plenty of words. The problem is coming up with the right words and getting them in the right order so that when someone else reads what I've written, they have half of chance of understanding what I'm trying to say.
I suppose I could take a writing class - and I might well do that eventually, but it seems like the simpler thing to do is to just start writing more. Practice makes perfect and all that.
Seeing What Happens
Beyond the writing practice, the only other reason for doing this blog is to see what happens. I dont necessarily think I have a whole lot to say. I don't consider myself exceptionally smart, nor do I think I'm a deep thinker. And I'm certainly not an expert on anything in particular (I'm more a jack-of-all-trades kind of guy). But that doesnt seem to stop most people. And I'm not going to let it stop me either.
Maybe, if I'm really lucky, I'll manage to start a conversation or two of my own and actually get some feedback. Maybe I'll find out that I'm pretty normal and that my approach to doing software fits in with the way most other people do it. Or, maybe I'll find out that I'm way out in left field making mountains out of molehills and my writing really does suck as bad as I think it does. Either way is fine by me - at least I've learned something.
Subscribe to:
Posts (Atom)