[cgiapp] Best practice for CGI errors

[Mark Knoop]

> 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
>
>

Thanks for this. I like the look of JSON(P)... will investigate further as 
an alternative to XML. Re SOAP security it was just that I had working 
examples of clients accessing a proxy via ssl but I guess that there is no 
reason why I cannot use https with a normal CGI request - I just never have 
done (or at least not with a dynamic client as opposed to a browser). 
Username and password just get passed as normal parameters so as long as 
they are ssl'd that's fine.

Best, Mark