how to provide API for our system

Question

I have not had much experience with Webservices or API's.

We have a website built on Oracle->Sun App Server->Java->Struts2 framework. We have a requirement to provide an API for our system. This API will be used by other systems outside of our system. API is just for a simple SP that we have on our database. The other system does not want to connect to our DB to gain access to the SP but instead and an API as a 'webservice'

Can the community please shed some light on how to go about this? Will the API be put on our webserver? is that how the other system will connect to it? And how to go about creating a public API?

Answer 1

Some things you'll need to think about are:

• SOAP vs REST (http://stackoverflow.com/questions/90451/why-would-one-use-rest-instead-of-web-services)
• How will you handle authentication?
• Does it need to scale?

You might want to take a look at https://jersey.dev.java.net/.

It would also be helpful to look at how another company does it, check http://www.flickr.com/services/api/ for some ideas.

Answer 2

If you are using the Sun App Server, it should be fairly trivial to make an EJB exposed as a web service with the @WebService tag, and then have that EJB call the Stored Proceedure and return the data. The app server gives you tools to publish a WSDL which is what they will use to know how to call you API.

That being said, what sounds easy at 50,000 feet is a real pain to deal with all the details. First, what about security? Second, are WebServices really required, or is there a better communication mechanism that is more obvious, such as (at a minimum) REST, if not some simple servlet communication. And the hardest part: In exactly what format will you return this result set?

Anyway, you could be dealing with a bit of a political football here ("what, you don't know how to do web services, everyone knows that, etc.") so it can be a bit hard to probe the requirements. The good news is that publishing a web service is pretty trivial in the latest Java EE (much easier than consuming one). The bad news is that the details will be a killer. I have seen experienced web service developers spend hours on namespace issues, for example.

Answer 3

Soap or Rest or .. is one side of the medal and depends on what the clients want. The other (more) important thing is the api design itself. Shall it be stateless or stateful. Are clients co-located in the same VM (Appserver) or remote in the same LAN or even in a Wan. As soon as the communication goes over the wire, it gets slow due to serialization. So you want API methods to obtain bigger (but not too big) chunks of data at a time.

Or in other words, your question can not really be answered without knowing a lot more about what you want and need to do.