With a REST implementation you roll yourself, you'd just have to re-implement this stuff, wouldn't you? Or what am I missing?
No, you wouldn't. as generalk sayed in his comment (http://news.ycombinator.com/item?id=1053384), 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.
let's pretend you have a method called GetEmployeeByName(string name).
with REST you'll implement this method and allow your users to invoke it via http://myservice.com/employee/simpson. 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 implement HTTP.
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.
you see, with REST over HTTP you just skip the XML-generating-and-some-more-task and let HTTP do the work. why reinvent the wheel when HTTP is suited pretty well for this part of the task?
That's fine of course for the trivial example, but what if my third parameter is an array, and I want to see a sensible error if I pass a hash table? What are the rules for which parameters go in the URL, whether they are delimited by ".", "/", or something else, and when they come as JSON in the request body, and how many there are, and what format they should come in?
> find a library (or implement your own) that will generate all the needed XML files etc.
Is this a problem? Many many such libraries exist which make exposing RPC calls nearly as easy as writing function declarations. (After all, that's what it's for - remote functions.) When I'm writing normal functions, I don't pass a request type, and a parameter string with various arbitrary delimiters, along with a possible big blob of text, and use that to fit every possible function, dealing with it in my own individual ad hoc way, do I?
I have to admit that I haven't experimented a lot with REST, so maybe some REST-experts here on HN will help me out answering some of these questions or give feedback regarding the answers that will follow in the next paragraphs :)
regarding question 1:
I think it's all a question of how your method behaves -- or how it is implemented. if your method requires JSON, then you'll have to feed it JSON. if your method requires 2 parameters, then you'll have to give it 2 parameters (e.g. myservice.com/?param1=123¶m2=456).
regarding question 2:
no, it's definitely not a problem, until the library is not maintained anymore or god knows what else. well, yes, it's more intuitive to write a plain simple function then to construct a very complicated request string as you mentioned.
as I already stated above, I don't have enough experience with REST at the moment to give you a more precise response, so I hope this one suffices. I also hope that somebody here on HN with more experience in the REST field will answer your question more precisely, so I can learn a thing or two, too :)
No, you wouldn't. as generalk sayed in his comment (http://news.ycombinator.com/item?id=1053384), 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.
let's pretend you have a method called GetEmployeeByName(string name).
with REST you'll implement this method and allow your users to invoke it via http://myservice.com/employee/simpson. 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 implement HTTP.
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.
you see, with REST over HTTP you just skip the XML-generating-and-some-more-task and let HTTP do the work. why reinvent the wheel when HTTP is suited pretty well for this part of the task?
I hope this clarifies everything a little bit.