4 ms·

XML-RPC is just what it says, a protocol for calling remote functions, isn't it? It gives you a unified means to specify functions, along with parameters and t

XML-RPC is just what it says, a protocol for calling remote functions, isn't it? It gives you a unified means to specify functions, along with parameters and their types, and gives errors when the requests don't match the definition. With a REST implementation you roll yourself, you'd just have to re-implement this stuff, wouldn't you? Or what am I missing? Tricks like appending ".jpg" to the url seem a little hack-ish to me. That feels like a parameter. Now what if there are two parameters, how do I know which comes first if someone else wrote it who doesn't use the same style as I do? If I'm querying for an employee, is it clear that I should use employee/110.jpg and not employee.jpg/110 or employee/110/jpg or employee/110/query/jpg, or somethere else?

ramen 17y ago
Indeed. The parameter-passing mechanism is something XML-RPC decides for you, rather than leaving the task of string concatenation (or XML message-building) to you. One might even call this "opinionated".
generalk 17y ago
It gives you a unified means to specify functions, along with parameters and their types, and gives errors when the requests don't match the definition. 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 see things in the reverse: HTTP and REST give you a way to make requests, specify parameters, indicate errors, authenticate, etc. XML-RPC ignores all of that and makes you re-implement all of those things. Tricks like appending ".jpg" to the url seem a little hack-ish to me. That feels like a parameter. Now what if there are two parameters, how do I know which comes first if someone else wrote it who doesn't use the same style as I do? Those are meant to resemble file extensions, but they can be thought of as parameters. If I'm querying for an employee, is it clear that I should use employee/110.jpg and not employee.jpg/110 or employee/110/jpg or employee/110/query/jpg, or somethere else? It's not standardized, just like XML-RPC isn't. Either way you can read the documentation for your service and it'll tell you. Alternatively, in REST everything has a URI. This has two interesting properties: 1. You can always access a resource by its unique URI: http://example/employees/110.jpg http://example/employees/110.jpg 2. As seen on the WWW: hypermedia links. If you request /employees.json, for instance, I can provide a structure like: {name: "John Employee", related: { image: "http://example/employees/110.jpg", performance_review: "http://example/employees/110/review" } } Which means that with your response you can easily request those URIs and get the resources. Those URIs should never change (as mentioned), but HTTP provides for redirection if they do. XML-RPC does not provide for this at all. (edited for formatting)
- ramen 17y ago
  HTTP and REST give you several ways to make requests (PUT vs. POST? Fall back on POST for clients that don't support PUT? How?), several ways to specify parameters (URL path fragments, query strings, headers, or POST data?), and a set of standard errors that you do not control and which are not used consistently. I like how XML-RPC ignores all of that, because there are too many ways to do the same thing.
  - generalk 17y ago
    If that works for you, awesome. HTTP and REST give you several ways to make requests (PUT vs. POST? Fall back on POST for clients that don't support PUT? How?) PUT is used for update operations and POST generally for create. Your library will abstract away the "client doesn't support sending PUT" so you don't deal with it. Same way XML-RPC libs abstract away the ugly portions of XML-RPC. several ways to specify parameters (URL path fragments, query strings, headers, or POST data?) Yes, there's more than one way to do that. Generally a service's documentation tells you what to do, so I'm not seeing the issue, but I concede that someone might find fault with that. and a set of standard errors that you do not control and which are not used consistently Whereas XML-RPC gives nothing, and everything is re-invented every time. Again, if that's a better solution for you, awesome, but for me the "some people use HTTP status codes to mean different things" isn't a reason to throw the whole thing out.
    - ramen 17y ago
      PUT is used when you know the URL you are creating and you can send a whole resource. This, by convention, has been interpreted by many to mean updates, but not everyone agrees. The Basecamp API for instance uses "PUT /todo_items/#{id}/complete.xml" to mark a TODO item as complete. Is this creating a new "complete" resource, or updating a "todo_item" resource? Either way, when trying to make an API fit the REST style, one must fit everything into the standard verb / filesystem-like mold. With plain-old RPC, you name your methods whatever makes sense to you, using your time-earned experience in designing regular libraries, and you don't waste a moment on these nitpicky decisions. The lack of consistent client support for PUT and DELETE further complicates this issue. As you say, you can abstract away the emulation of these verbs, but what library are you speaking of? A single-purpose solution to wrapping a particular REST interface? Or a one-size-fits-all REST wrapper that works with any server? I'm not sure the latter is possible, since there are once again multiple ways to do this - "?_method=PUT"? X-HTTP-Method-Override? Or something else entirely... it's not standardized, and REST isn't a spec, it's just a style, so everyone does it their own way. All of this so that we can write "PUT" at the beginning of the HTTP request line instead of further down or to the right? What is the actual benefit to all of this extra work? The biggest issue with parameter-passing style is the lack of a standard way to pass complex data structures. It's as if every function took only a single argument, a string, and had to run a regex on it, splitting the results on delimiters, each in its own special way. If a regular software library were written this way, it would be appalling. At least PHP gave it a shot, with its arr[]1=&arr[]=2... syntax, but nobody's going to standardize on that, since query strings are unfashionable now, and nobody likes PHP anymore. I honestly think we should go back to query strings and stop embedding data in URLs because at least you get named parameters. And if you subscribe to the HATEOAS camp, they're more RESTful since we already have one standardized, well-documented way to provide clients all they need to build them (HTML forms). You're right, just because people don't use something consistently doesn't mean you should throw the whole thing out. I didn't mean to imply that. What I stand by, however, is that HTTP status codes were not designed for APIs, and that as a result they are guaranteed to be used inconsistently when used for the purpose of designing APIs. At least with all-custom error codes there's no expectation that everyone will interpret the HTTP standard correctly as applied to a problem it was never intended to solve.
_giu 17y ago
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 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 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.
- WilliamLP 17y ago
  > you'll implement this method and allow your users to invoke it via http://myservice.com/employee/simpson 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?
  - 17y ago
tjpick 17y ago
> Tricks like appending ".jpg" to the url seem a little hack-ish to me. That feels like a parameter. that feels like a file type. If there is more than one representation available then it's a parameter, indeed, but the standard place to put that is on the end of the filename. Surely it's clear that: employees is the collection; employees/110 is a specific employee; employees/110.jpg is the jpeg representation of said employee.
- akronim 17y ago
  Shouldn't you be using HTTP Accept headers to specify the format(s) you want? (rather than file extensions in the URL)
  - tjpick 17y ago
    the spec says they can be used for that and you could easily have a server that checks the HTTP Accept if there is no extension. Most likely you need to hyperlink to many of the resources so you're going to need the extension anyway (eg /employees/110.html has an img src="employees/110.jpg") If it's for a programmatic client, not a browser, the HTTP Accept would probably be sufficient.

ramen 17y ago

Indeed. The parameter-passing mechanism is something XML-RPC decides for you, rather than leaving the task of string concatenation (or XML message-building) to you. One might even call this "opinionated".

generalk 17y ago

It gives you a unified means to specify functions, along with parameters and their types, and gives errors when the requests don't match the definition. 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 see things in the reverse: HTTP and REST give you a way to make requests, specify parameters, indicate errors, authenticate, etc. XML-RPC ignores all of that and makes you re-implement all of those things. Tricks like appending ".jpg" to the url seem a little hack-ish to me. That feels like a parameter. Now what if there are two parameters, how do I know which comes first if someone else wrote it who doesn't use the same style as I do? Those are meant to resemble file extensions, but they can be thought of as parameters. If I'm querying for an employee, is it clear that I should use employee/110.jpg and not employee.jpg/110 or employee/110/jpg or employee/110/query/jpg, or somethere else? It's not standardized, just like XML-RPC isn't. Either way you can read the documentation for your service and it'll tell you. Alternatively, in REST everything has a URI. This has two interesting properties: 1. You can always access a resource by its unique URI: http://example/employees/110.jpg http://example/employees/110.jpg 2. As seen on the WWW: hypermedia links. If you request /employees.json, for instance, I can provide a structure like: {name: "John Employee", related: { image: "http://example/employees/110.jpg", performance_review: "http://example/employees/110/review" } } Which means that with your response you can easily request those URIs and get the resources. Those URIs should never change (as mentioned), but HTTP provides for redirection if they do. XML-RPC does not provide for this at all. (edited for formatting)

ramen 17y ago
HTTP and REST give you several ways to make requests (PUT vs. POST? Fall back on POST for clients that don't support PUT? How?), several ways to specify parameters (URL path fragments, query strings, headers, or POST data?), and a set of standard errors that you do not control and which are not used consistently. I like how XML-RPC ignores all of that, because there are too many ways to do the same thing.
- generalk 17y ago
  If that works for you, awesome. HTTP and REST give you several ways to make requests (PUT vs. POST? Fall back on POST for clients that don't support PUT? How?) PUT is used for update operations and POST generally for create. Your library will abstract away the "client doesn't support sending PUT" so you don't deal with it. Same way XML-RPC libs abstract away the ugly portions of XML-RPC. several ways to specify parameters (URL path fragments, query strings, headers, or POST data?) Yes, there's more than one way to do that. Generally a service's documentation tells you what to do, so I'm not seeing the issue, but I concede that someone might find fault with that. and a set of standard errors that you do not control and which are not used consistently Whereas XML-RPC gives nothing, and everything is re-invented every time. Again, if that's a better solution for you, awesome, but for me the "some people use HTTP status codes to mean different things" isn't a reason to throw the whole thing out.
  - ramen 17y ago
    PUT is used when you know the URL you are creating and you can send a whole resource. This, by convention, has been interpreted by many to mean updates, but not everyone agrees. The Basecamp API for instance uses "PUT /todo_items/#{id}/complete.xml" to mark a TODO item as complete. Is this creating a new "complete" resource, or updating a "todo_item" resource? Either way, when trying to make an API fit the REST style, one must fit everything into the standard verb / filesystem-like mold. With plain-old RPC, you name your methods whatever makes sense to you, using your time-earned experience in designing regular libraries, and you don't waste a moment on these nitpicky decisions. The lack of consistent client support for PUT and DELETE further complicates this issue. As you say, you can abstract away the emulation of these verbs, but what library are you speaking of? A single-purpose solution to wrapping a particular REST interface? Or a one-size-fits-all REST wrapper that works with any server? I'm not sure the latter is possible, since there are once again multiple ways to do this - "?_method=PUT"? X-HTTP-Method-Override? Or something else entirely... it's not standardized, and REST isn't a spec, it's just a style, so everyone does it their own way. All of this so that we can write "PUT" at the beginning of the HTTP request line instead of further down or to the right? What is the actual benefit to all of this extra work? The biggest issue with parameter-passing style is the lack of a standard way to pass complex data structures. It's as if every function took only a single argument, a string, and had to run a regex on it, splitting the results on delimiters, each in its own special way. If a regular software library were written this way, it would be appalling. At least PHP gave it a shot, with its arr[]1=&arr[]=2... syntax, but nobody's going to standardize on that, since query strings are unfashionable now, and nobody likes PHP anymore. I honestly think we should go back to query strings and stop embedding data in URLs because at least you get named parameters. And if you subscribe to the HATEOAS camp, they're more RESTful since we already have one standardized, well-documented way to provide clients all they need to build them (HTML forms). You're right, just because people don't use something consistently doesn't mean you should throw the whole thing out. I didn't mean to imply that. What I stand by, however, is that HTTP status codes were not designed for APIs, and that as a result they are guaranteed to be used inconsistently when used for the purpose of designing APIs. At least with all-custom error codes there's no expectation that everyone will interpret the HTTP standard correctly as applied to a problem it was never intended to solve.

_giu 17y ago

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 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 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.

WilliamLP 17y ago
> you'll implement this method and allow your users to invoke it via http://myservice.com/employee/simpson 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?
- 17y ago

tjpick 17y ago

> Tricks like appending ".jpg" to the url seem a little hack-ish to me. That feels like a parameter. that feels like a file type. If there is more than one representation available then it's a parameter, indeed, but the standard place to put that is on the end of the filename. Surely it's clear that: employees is the collection; employees/110 is a specific employee; employees/110.jpg is the jpeg representation of said employee.

akronim 17y ago
Shouldn't you be using HTTP Accept headers to specify the format(s) you want? (rather than file extensions in the URL)
- tjpick 17y ago
  the spec says they can be used for that and you could easily have a server that checks the HTTP Accept if there is no extension. Most likely you need to hyperlink to many of the resources so you're going to need the extension anyway (eg /employees/110.html has an img src="employees/110.jpg") If it's for a programmatic client, not a browser, the HTTP Accept would probably be sufficient.