[cgiapp] Best practice for CGI errors

[Michael Peters]

Mark Knoop wrote:

> ...while I am here (and acknowledging that this is slightly off topic 
> but at the same time it is probably somehting that many of you have had 
> much experience in 'real-world' scenarios) can I ask whether CGI::App 
> users have any favourite ways to do it re 'web services' ie remote 
> methods/apis that do something then return some data? SOAP, XML-RPC, 
> bespoke XML/JSON/other in response to GET/POST with CGI params, any 
> other approach? My methods and responses are very simple. 

For simplicity (speed, human readability, etc) you can't beat JSON. I love it. And if you allow some 
JSONP you can make it easy for people to use your service to build mashups. You can have your 
clients make submissions that are simple requests with a JSON document as part of the request or you 
can use normal CGI style parameters. Really up to you.

I'd avoid SOAP if I were you. It's overly complex and there are a lots of different variations. 
Compatibility between systems is not given and can be a real big headache.

> It would be 
> nice to have hassle free security already there - this was the one 
> advantage to SOAP - the main disadvantage being a lack of understanding 
> on my part...

I could be completely wrong, but I don't see how SOAP provide security to your application? You 
still need to implement whatever security scheme you decide on and you can always use SOAP's basic 
security model for your own application if you want. But as far as security in web services goes 
I've had good success with the following:

1) username and passwords. Treat it just like other web stuff. The only difference is that you don't 
really use a cookie, you just make them send the username and password on every request.

2) crytographic token. Very similar to #1 but instead of passing a username and pw with each request 
it's just a simple token. You'd give each client a separate token which you can then verify on each 
request. You can also embed data into the token itself like client id, etc. You can even embed 
something like the origin IP address in there so that client can't give your tokens away to other 
people.

-- 
Michael Peters
Plus Three, LP