<i>With a REST implementation you roll yourself, you'd just have to re-implement this stuff, wouldn't you? Or what am I missing?</i><p>No, you wouldn't. as generalk sayed in his comment (<a href="http://news.ycombinator.com/item?id=1053384" rel="nofollow">http://news.ycombinator.com/item?id=1053384</a>), it's the reverse, namely with REST over HTTP you'll make use of HTTP, which perfectly provides the functions to accomplish the task of invoking a method remotely without having to implement this important part on your own. I'll try to make an example.<p>let's pretend you have a method called <i>GetEmployeeByName(string name)</i>.<p>with REST you'll implement this method and allow your users to invoke it via <a href="http://myservice.com/employee/simpson" rel="nofollow">http://myservice.com/employee/simpson</a>. the invocation, parameter-passing, error-handling etc. is done via HTTP, so theoretically no work is needed on this part, since you don't have to <i>implement</i> HTTP.<p>with XML-RPC the thing is pretty different. you'll implement the method, but what you have to do now is -- as described in the article -- find a library (or implement your own) that will generate all the needed XML files etc.<p>you see, with REST over HTTP you just skip the XML-generating-and-some-more-task and let HTTP <i>do</i> the work. why reinvent the wheel when HTTP is suited pretty well for this part of the task?<p>I hope this clarifies everything a little bit.