It sounds like you want to create a web-service that other people can connect to, send answers and retrieve a result.
If that's the case, you've got three options, SOAP, XML-RPC and REST. If it's a simple API, SOAP (and probably XML-RPC) will be overkill - you don't want to have to create a WSDL file, install a SOAP server library (although, Zend_Soap is decent enough). REST on the other hand will allow anyone to easily consume your API.
Let's look at an example, say you want to provide a simple "sum" service (i.e., add a few numbers), you could have a URI scheme like this:
http://example.com/sum
to sum the numbers 5, 8 and 9 your web service users would simpy execute an HTTP GET to
http://example.com/sum/5/8/9
let's pretend for a moment that summing is actually a very computationally expensive task, by using REST and a GET you can take advantage of HTTP caching so that your server isn't constantly hit when someone sends the same parameters for calculation.
If your web service has a resource that isn't side-effect free (i.e. it changes something in a database) you should use PUT, POST or DELETE (PUT for updates, POST for creating and DELETE for delete) as the HTTP specs state the GETs shouldn't have side-effects. Similarly, PUT and DELETE should be safe to repeat if you get an error back or the network connection times out.
There's a good talk (video and slides) on REST here: http://www.parleys.com/display/PARLEYS/Home#talk=31817742
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…