{
"attachments": [],
"comments_archived": true,
"date": "2002-04-18T00:58:41.000Z",
"layout": "post",
"title": "REST. What is it good for?",
"wordpress_id": 82,
"wordpress_slug": "oooaob",
"wordpress_url": "http://www.decafbad.com/blog/?p=82",
"year": "2002",
"month": "04",
"day": "17",
"isDir": false,
"slug": "oooaob",
"type": "entry",
"postName": "2002-04-17-oooaob",
"html": "I don't get REST, specifically in the context of it being the RightThing to do web services. I see many vagueries about how it's \"more scalable\" and more \"right\" and better in theory and there's a big dissertation on it and everything. Eventually I will get down to reading it. On the surface, it seems like a big dud to me. But, it looks like a lot of smart people are into it, so I assume there's something to it since I don't know much yet.
\nThis is why I love Busy Developer Guides, by the way. They're for busy developers. Like me.
\nI don't suppose anyone could point me to something that lays it out for me? Like... why is XmlRpc considered harmful by REST fans? And what's an example app I could use REST for that will just so obviously convince me that I need to drop my XML-RPC ways?
\n\n\n\n\n\nshortname=oooaob
\n\n\n\n",
"body": "I don't get REST, specifically in the context of it being the RightThing to do web services. I see many vagueries about how it's \"more scalable\" and more \"right\" and better in theory and there's a big dissertation on it and everything. Eventually I will get down to reading it. On the surface, it seems like a big dud to me. But, it looks like a lot of smart people are into it, so I assume there's something to it since I don't know much yet.
\r\nThis is why I love Busy Developer Guides, by the way. They're for busy developers. Like me.
\r\nI don't suppose anyone could point me to something that lays it out for me? Like... why is XmlRpc considered harmful by REST fans? And what's an example app I could use REST for that will just so obviously convince me that I need to drop my XML-RPC ways?
\r\n\r\nshortname=oooaob\r\n\r\n\r\n ",
"parentPath": "./content/posts/archives/2002",
"path": "2002/04/17/oooaob",
"summary": "I don't get REST, specifically in the context of it being the RightThing to do web services. I see many vagueries about how it's \"more scalable\" and more \"right\" and better in theory and there's a big dissertation on it and everything. Eventually I will get down to reading it. On the surface, it seems like a big dud to me. But, it looks like a lot of smart people are into it, so I assume there's something to it since I don't know much yet.\nThis is why I love Busy Developer Guides, by the way. They're for busy developers. Like me.\nI don't suppose anyone could point me to something that lays it out for me? Like... why is XmlRpc considered harmful by REST fans? And what's an example app I could use REST for that will just so obviously convince me that I need to drop my XML-RPC ways?",
"needsBuild": true,
"prevPostPath": "2002/04/17/oooaoa",
"prevPostTitle": "GoogleToRss seems broken now",
"nextPostPath": "2002/04/18/oooaoc",
"nextPostTitle": "Google Boxes? Permasearch?"
} ![](\"http://www.gravatar.com/avatar.php?gravatar_id=bb524c061054ff777e6677288faa1ead&size=32&default=http://mediacdn.disqus.com/1320279820/images/noavatar32.png\"/)
\r\n Hugh\r\n XMLRPC is \"considered harmful\" just because it's RPC, and the assumption is that you wait for the return value of a remote call. SOAP is very often used synchronously, too.\r\n\r\nhttp://www.fawcette.com/xmlmag/2002_04/magazine/departments/endtag/\r\n \r\n \r\n \r\n ![](\"http://www.gravatar.com/avatar.php?gravatar_id=743ec87899694a206abd6bdca8fed5fc&size=32&default=http://mediacdn.disqus.com/1320279820/images/noavatar32.png\"/)
\r\n Ken MacLeod\r\n RPC is not considered harmful because it is synchronous (you make the call and wait for the return value before proceeding).\r\n\r\nI outlined two reasons why Internet-scale RPCs are harmful in, unsurprisingly, Web RPCs Considered Harmful[1] before REST became a common term.\r\n\r\n1) Security.\r\n\r\n RPCs encourage unique, new code to be developed to answer every API call. Even security concious people often have bugs in their code. There are very few Web RPC resources that discuss programming techniques for security, but they are similar to security issues in CGI (and that's an important similarity to note).\r\n\r\nREST encourages database-like storage servers, with declarative access controls and filters; WebDAV for data, if you will. Like HTTP servers themselves, REST application servers are likely to be widely deployed, mature server code bases. Outside of static HTTP servers and, arguably, Linda-style systems, I'm still waiting for these RESTful servers to appear.\r\n\r\nUsing a Linda-style REST server also allows one to decouple what application code is necessary from being directly accessible through the public internet. With a REST server in-between, the public clients access the REST server from outside, and the RESTful application accesses the REST server from some safely sequestered system \"almost inside.\"\r\n\r\n2) Monopolization, lock-in, or fragmentation.\r\n\r\nWith RPCs, you have two levels of interface definition: the data model and the procedure API. A data model can be made flexible (Sam Ruby's Coping with Change[2]), but APIs describe behavior, and behavior can be very inflexible. Intentional or otherwise, APIs more easily lock one into the API author's way of doing things.\r\n\r\nREST encourages applications to focus almost entirely on the data model and limit the behavior as much as possible. In REST, the \"main\" behaviors of GET, PUT, TAKE, LOCK (depending on the RESTful server being used, there are more then just HTTP) are kept to a minimum. The application grows primarily by providing new data models, not by new methods to access them.\r\n\r\n----\r\n\r\n[1] http://monkeyfist.com/articles/514\r\n[2] http://radio.weblogs.com/0101679/stories/2002/03/15/copingWithChange.html\r\n \r\n \r\n \r\n
Archived Comments
\n\n- \n
\n\n![](\"http://www.gravatar.com/avatar.php?gravatar_id=bb524c061054ff777e6677288faa1ead&size=32&default=http://mediacdn.disqus.com/1320279820/images/noavatar32.png\")
\nHugh\n \n\n\n \n\n\nXMLRPC is \"considered harmful\" just because it's RPC, and the assumption is that you wait for the return value of a remote call. SOAP is very often used synchronously, too.\nhttp://www.fawcette.com/xmlmag/2002_04/magazine/departments/endtag/ \n\n\n \n- \n
\n\n![](\"http://www.gravatar.com/avatar.php?gravatar_id=743ec87899694a206abd6bdca8fed5fc&size=32&default=http://mediacdn.disqus.com/1320279820/images/noavatar32.png\")
\nKen MacLeod\n \n\n\n \n\n\nRPC is not considered harmful because it is synchronous (you make the call and wait for the return value before proceeding).\nI outlined two reasons why Internet-scale RPCs are harmful in, unsurprisingly, Web RPCs Considered Harmful[1] before REST became a common term.\n1) Security.\nRPCs encourage unique, new code to be developed to answer every API call. Even security concious people often have bugs in their code. There are very few Web RPC resources that discuss programming techniques for security, but they are similar to security issues in CGI (and that's an important similarity to note).\nREST encourages database-like storage servers, with declarative access controls and filters; WebDAV for data, if you will. Like HTTP servers themselves, REST application servers are likely to be widely deployed, mature server code bases. Outside of static HTTP servers and, arguably, Linda-style systems, I'm still waiting for these RESTful servers to appear.\nUsing a Linda-style REST server also allows one to decouple what application code is necessary from being directly accessible through the public internet. With a REST server in-between, the public clients access the REST server from outside, and the RESTful application accesses the REST server from some safely sequestered system \"almost inside.\"\n2) Monopolization, lock-in, or fragmentation.\nWith RPCs, you have two levels of interface definition: the data model and the procedure API. A data model can be made flexible (Sam Ruby's Coping with Change[2]), but APIs describe behavior, and behavior can be very inflexible. Intentional or otherwise, APIs more easily lock one into the API author's way of doing things.\nREST encourages applications to focus almost entirely on the data model and limit the behavior as much as possible. In REST, the \"main\" behaviors of GET, PUT, TAKE, LOCK (depending on the RESTful server being used, there are more then just HTTP) are kept to a minimum. The application grows primarily by providing new data models, not by new methods to access them.\n----\n[1] http://monkeyfist.com/articles/514\n[2] http://radio.weblogs.com/0101679/stories/2002/03/15/copingWithChange.html \n\n\n \n
\n\n\n\n
\n