Hello. I am trying to understand what these services are and their use. I have googled them and looked at their wiki, but I am still a little lost. From what I got is that they are different ways to communicate with other applications? So does that mean it's like JSON? Sorry for the newb question, but please help me understand by perhaps describing it a better/different way than on wikipedia. I would also be greatful if you could explain a short example of their use and when/why. Thank you so very much!

Quote

Communication is a central issue in all three.

Quote

Sort of, in that JSON also deals with a communication related issue. But REST, JSON and XML-RPC and SOAP all have different concerns. XML-RPC and SOAP can be most tightly grouped, as SOAP can be seen as the successor of XML-RPC.

JSON is probably easiest to understand first. JSON is concerned with the format of data. Let's switch to the real world analogy, which is two people talking to each other. The medium of communication is one issue. But that's not an issue here (they are talking to one another). This involves the usage of the human body (mouth, vocal cords, the bone structure, etc.) to create a series of perceivable sounds that are audible to the other person. What's interesting is the language. You can hear Japanese, but can you understand it?

JSON is a format specification. If two applications need to communicate data, JSON is a way of formatting that data. So if both applications can understand JSON, all is well. JSON itself doesn't concern itself much more than the objectives of its format specification (one objective for example, is that the format is human readable). The larger objectives or motivations to use JSON aren't really a direct concern.

Then, moving on to XML-RPC. XML-RPC's end goal is actually a bit more complicated, but a central concept is message passing. So we have the question of how two applications communicate with one another. It seems an awful lot like JSON, but wait a minute. JSON itself concerned itself with a specific issue: how should data be formatted. It doesn't answer the question of how it should be transported from one application to another. For example, I am writing in English right now. English itself is not medium specific. I am writing it at the moment, but I can also speak it. Speaking and writing are questions of transport. The language itself is the format of the information.

So XML-RPC needs to address two questions here. If two applications need to pass messages, what medium or transport mechanism do they use, and how should the transmitted data be formatted? XML-RPC gives a defined answer to both questions. The transport mechanism is HTTP (your web browser and web servers use it), and the format is XML. Well, that answer doesn't even cut it.

Because XML-RPC has an end objective. Now to a programmer's issue. You work for a company that has a phone directory. Given a name, the company has an online web application that will tell you the corresponding phone number. You want to write a small program on your computer that can do the above. It would be awfully convenient if your program could just ask the web application for the phone number. But how? How can you invoke this functionality? Effectively, you need to make a remote procedure call. It's remote, because it's not local to your application. It's somewhere else on the internet. It's a procedure call because that is what you are doing. You have some parameters that are passed to what resembles a function. And this function will ideally do something and maybe throw something back out.

So XML-RPC defines a vocabulary (in the XML format) for making these kind of procedure calls. If your application uses XML-RPC, and so does the web application, then you can make the request. XML-RPC tells you how to transmit the data, it tells you how to format the call, and it tells you exactly what to write to pass in all that information. And if the web application tries to give an answer back to you, it will also do so through XML-RPC, which you can understand.

SOAP is like XML-RPC, but the difference is that it doesn't say that HTTP has to be used to transport messages. It's protocol neutral. I don't know the details, and that's not really what you should care about either. Just know that SOAP isn't fixed to HTTP (although that's an option with SOAP).

REST is the hardest to understand. That's because REST isn't about message-formatting or transmitting or procedure calls. It's more of a set of principles. I can't really explain it without recreating the Wikipedia article, but you should recognize that REST isn't about HTTP, about web services, or a specific implementation. It's more like design principles that can be applied. So a RESTful web service doesn't mean that REST is a way to design web services. It means that the web service has been designed so that it follows the abstract principles of REST.

Thank you very much! That's exactly what I was looking for. We haven't touched upon this topic in college yet and I was just wondering. It doesnt seem to look like it's in any of my future classes either, but it seems important since i see being written about on the web so often. Perhaps some outside learning is needed.

Dam good explanation. Bravo, bravo.