As we start updating and building our new APIs here at PodShow, I have to wonder which format most people prefer. I know internally here at the office, everyone has their own preference and experiences, but what do YOU want? The current Authoring API is built utilizing XMLRPC but we are planning on updating the APIs eventually and creating the new ones in different formats.
So if you have a preference, now is your chance to speak up! Leave a comment in the blog or send audio/video comments to developers@podshow.com and we will work them into a future Devcast and publish them to the site.
I personally like REST, but that is just one mans opinion.
Personally i don’t care for XML-RPC or SOAP they seem very akward to work with. In my opinion REST is best, it just makes sense without re-inventing the wheel.
As far as the formats offered by the API, we already offer XML/RSS but think we should have more choices available. JSON is by far the easiest to work with when exchanging data but XML is still very good for that as well.
I have some ideas i would like to present about offering more RESTful urls and services. Still a work in progress but will try to get it out as soon as possible.
As it appears to me, it’s only about exposing underlying functionality via RPC. SOAP/WSDL is a good option if you target larger client applications. There are good Stub-Generators for c# or java, so once you expose your services via SOAP and describe them via WSDL it will be a matter of few clicks for a developer to get a hello world application up and running.
On the other hand SOAP does include a little bit more work on the server-side. If you are lucky (depending on the frameworks/technology being used on the server), you can use a wrapper around the core-services which will auto-expose the services via SOAP and also take care about the WSDL. There are also downsides of such auto generated endpoints. For example you will expose internals of the software architecture to the service consumers. Also, if you do some minor changes to the service methods, it might break many clients since you have no abstraction layer between your core-services and the SOAP interface.
The solution to this problem will be using SOAP as it’s meant to be used. Think about SOAP as Message-Interface, not as an RPC mechanism. Then handwrite a WSDL which defines how the messages should look like and write a single endpoint which parses the messages and delegates them to the backend.
Regarding XML-RPC and REST or JSON, they are great if you plan to develop “Web”-Based clients. Using AJAX on the clientside or PHP on the serverside. If it comes to more complex standalone / GUI Applications they are rather unhandy and require more “parsing” and “service-wrapping” on the server side when compared to the SOAP variant.
I hope this helps you to decide which technology could be used in your scenario.
Let me know if i can help you an further! I would love to.
Cheers!
Paul.
Personally i prefer Soap/WSDL. There are good proxy generators for c# or java. So you have a jump start using the underlying functionality. I have played with the xml-rpc api and it took a while before it was running fine. I have developed a lot of Soap/WSDL applications and used it in applications and the service is more or less self describing
regards,
Mark
I only just found the authoring API today after getting a little tired of the PDN web interface.
I do a bit of perl scripting as well as podcasting and the XML-RPC took only a few minutes to get going in perl.
I don’t know much about Rest/JSON/SOAP, but XML-RPC seems very easy to get going…
Nigel.
Yahoo Pipes offer a JSON feed input.