Today I am attending the DC PHP Conference and presenting on REST Web Services*. Despite the fact that much of the technical world has been building and using REST for quite a few years, many of the technologists and geeks in and around DC haven't been exposed to them.
First, a note aboute Web Services. Some people try to make them wildly complicated, but the concepts are pretty simple. You make a request to another system asking for or giving particular information and then you get the results some point in the future. Think of ordering a pizza: You get the number, call and place your order using the menu, and your pizza arrives warm and tasty a while later. Other than some mozzarella, Web Services are basically the same.
But why would you want to use Web Services?
Let's say you have a system like dotProject. Your entire team is logging their time, updating the status of the project, and generally providing useful information up the line for once. Unfortunately, the system you use for generating paychecks and invoices can't interact with dotProject… so how do you get the data? How can you make your systems play well together when they speak different languages? This is where Web Services come into to play. If you can have both systems push a bit of XML back and forth, they can speak the same language.
So if Web Services are so useful, why isn't everyone using them?
Unfortunately, the phrase “Web Services” was quickly latched onto by the marketing drones and polluted to mean everything and nothing all at once: “Web Services would become the new standard where everyhing could interact and no actual code would have to be written!” I'll never forget the day my boss told me that he was going to build a 100% XML application… huh? Add to this confusion that a few Enterprisy-geeks got into the fray and you get the creature which is SOAP, WSDL, and a variety of other “standards”… I could go for hours, but you get the point: marketers + enterprise geeks = a non-solution for mere mortals.
In walks REST… REST is very appealing at. It's XML, it's simple, and you don't need to learn yet another application server. In fact, you – as a consumer of information – don't even need to write XML, you just need to parse it. The only time you need to create XML is when you're updating information. By using this strategy instead of SOAP, I was able to implement the first half of the dotProject REST interface in less than 200 lines of code.
* The presentation slides will be made available online within a few days.