4 ms·

Two things: * You're going to have to support your SOAP endpoint anyway, so only maintain libraries for your SOAP endpoint (at least for now). Having a PHP lib

Two things: * You're going to have to support your SOAP endpoint anyway, so only maintain libraries for your SOAP endpoint (at least for now). Having a PHP library for SOAP and a PHP library for REST will just confuse people to no end. * Put up a form on your web site that says "Put your email in to get early access to our REST API" and then see if anyone actually bites. Just because someone on a survey said they wanted REST instead of SOAP doesn't mean that you have to run off and do it, or that they wouldn't necessarily use the SOAP API if they actually had to solve a problem with your API. We built some really interesting stuff on SOAP and WS-* in the 2002-2003 era, and it's always fun to see development trends go in circles.

faxman 15y ago
> only maintain libraries for your SOAP endpoint (at least for now Check. This was the decision that came out of today's product meeting after reading responses here. > Put up a form... Check. Already did this a couple weeks ago at www.interfax.net/en/dev/rest. Already got a few bites. > Just because someone on a survey said they wanted REST instead of SOAP ... I agree. However, we ran several variations of the survey including one where developers had an opportunity to say that not having REST is a show-stopper for them, which got us worried. Strangely, most of those who insisted on REST develop in environments which have the strongest SOAP support, like C#, PHP, and Java. This got me thinking that we might be dealing with fashion issues more than practical issues...
deleted 15y ago
[deleted]
deleted 15y ago
[deleted]
deleted 15y ago
[deleted]