If you want something really simple to expose your module as a Web Service I would use HTTP::Server::Simple::CGI. Note that the vanilla module can only attend one requst at a time, but you also add Net::Server for forking.
I would personally avoid the use of SOAP, XMLRPC and alike. IMHO these protocols add a lot of useless overhead and create all sorts of security issues. Since to properly apply security measures you have to inspect each package and understand it's contents, just to mention one of many flaws.
To expose code correctly over HTTP, I would highly recommend to learn and use HTTP (Representational_State_Transfer) for what it was designed, and map the HTTP semantics to your api, avoiding the use of HTTP as a transport protocol, instead of tranfer.
Basically this boils down to:
-
Think of your HTTP transactions as exchange of resources, and that each resource should have enough information for your client to figure out what to do with it (i.e. the resource should represent it's state). This can also be translated as: use HTTP to transfer data to and from the server, and the data should be enough for the client to make decisions on it. Never use HTTP to transport other protocols, for example, never put verbs on the URL, only nouns. And never use cookies and sessions (<grin> this will surely raise quite a polemic here).
-
Use HTTP methods for what they are:
-
GET is used to fetch a resource, it should be idempotent and never be used to modifiy stuff on the server.
-
POST is usually used to create new resources on the server. Your milage may vary.
-
PUT is usually used to update existing resources on the server. Your milage may vary.
-
DELETE is used to delete resources on the server.
-
HEAD, OPTIONS, etc. are used to obtaing information on your resource and other options.
-
Use the correct HTTP return codes for every transaction.
-
Use the correct HTTP headers for the types on content encodings, character sets, etc. etc.
-
Always think of ways to take advantage of caches. For example on data that is not likely to change you can use the appropriate HTTP Caching Headers and never have to go again to a database to fecth this data, even better, your client may use it's own cache and never even have to call you again to access the resource (it can access it off-line!).
If you follow these simple recommendations your Web Services will be secure, simple, elegant, swift, and highly scallable.
