Comment by _giu | Hacker News Reader

Comment by _giu | Hacker News Reader

Parent Full thread

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?

I hope this clarifies everything a little bit.

> you'll implement this method and allow your users to invoke it via http://myservice.com/employee/simpson

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&param2=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 :)

Reply on news.ycombinator.com