API for an online database.

[Armitage]

So we have a site that we're going to be publishing "soon". Perl scripting with a MySQL DB behind it. We would like to also develop an API that users could incorporate directly into their applications to access the database over the net and retrieve data. My guess is we'd publish a reference implementation in some scripting language (probably Perl or Python), and folks can reimplement in the language of their choice.

Any suggestions on how to go about this? My first thought is to just have the API functions send a regular http request with the function name & parameters as get args to a CGI handler script on the server side that processes the request, and sends back the data. On receiving the data, the API function parses it out and inserts it into a native data structure.

Sound reasonable? Ideas? Suggestions?

 

[MrChad]

Sounds like a web service. The client-side calls will easily work across multiple platforms and languages.

Here's a quick and dirty article that explains how to set up a SOAP server in Perl. I'm sure there are other guides out there.

 

[Armitage]

Cool. I figured I wasn't the first guy to need something like this!

 

[DaveSimmons]

SOAP is shiny new, but adds overhead compared to just using CGI code. Use SOAP if it saves you a lot of time, but don't use it just because you can.

SOAP, like XML, doesn't magically make servers and clients interoperate. You not only have to spend time on the WSDL, but both the client and server need to use XML + SOAP toolkits for the transaction, and that only gets you parameter encoding and decoding, both ends still need to write code to send data and process the recieved results.

 

[Armitage]

Originally posted by: DaveSimmons
SOAP is shiny new, but adds overhead compared to just using CGI code. Use SOAP if it saves you a lot of time, but don't use it just because you can.

SOAP, like XML, doesn't magically make servers and clients interoperate. You not only have to spend time on the WSDL, but both the client and server need to use XML + SOAP toolkits for the transaction, and that only gets you parameter encoding and decoding, both ends still need to write code to send data and process the recieved results.

So, you're suggesting that something along the lines of my original suggestion my be a more efficient way to go?

Although, I doubt that performane is really my primary driver here ... more likely it's ease of implementation & maintenence.

Are SOAP libraries available for most platforms & languages ... especially Windows, SGI, & Linux/C C++ & Java?

Well, off to do some reading...
Thanks

 

[arcain]

Originally posted by: Armitage

Originally posted by: DaveSimmons
SOAP is shiny new, but adds overhead compared to just using CGI code. Use SOAP if it saves you a lot of time, but don't use it just because you can.

SOAP, like XML, doesn't magically make servers and clients interoperate. You not only have to spend time on the WSDL, but both the client and server need to use XML + SOAP toolkits for the transaction, and that only gets you parameter encoding and decoding, both ends still need to write code to send data and process the recieved results.

So, you're suggesting that something along the lines of my original suggestion my be a more efficient way to go?

Although, I doubt that performane is really my primary driver here ... more likely it's ease of implementation & maintenence.

Are SOAP libraries available for most platforms & languages ... especially Windows, SGI, & Linux/C C++ & Java?

Well, off to do some reading...
Thanks

Amazon has 2 interfaces for its web services. One is SOAP I believe (I don't remember, it was a while ago since I worked with it, and I chose not to use this option), and the other was more in line with what you described (passing in parameters in the URL, and returning data in the body. Amazon passed it back in XML). I had read somewhere that the majority of the users of Amazon's webservices was using hte second method (passing params in the URL).