As per my knowledge api and web services are used to fetch data from other websites.
So what's difference between them ?
Any Help!
EDIT
Can somebody please explain it with proper example ?
What is twitter and facebook api ? Can we say it's just a function or webservices to access their data.
A web service is just an API in HTTP clothing.
A web service is something delivered over the Internet for direct use by another computer (rather than a human).
An API is an Application Programming Interface. A website application might expose an API thorugh a web service. However, desktop applications like Excel or Word have APIs which have nothing to do with the web (they have VBA and COM based APIs).
Simlarly, a server application (eg. Joomla) might have a PHP based API that is used from withinthe server - ie. no web service necessarily involved.
All web services are APIs, but not all APIs are web services. One is a subset of the other.
Web Service is an API wrapped in HTTP.
All Web Services are API but APIs are not Web Services.
Web Service might not perform all the operations that an API would perform.
A Web Service needs a network while an API doesn't need a network for its operation.
An API doesn't need to be web based.
Web Services may also may not perform all of the operations one would expect from a full API.
API (application programming interface) is a list of methods and classes exposed by a programmer to use by other programmers, so eg if you use Twitter or Facebook API in your programs, you can make it cooperate with Twitter and Facebook, and do many useful things. :-)
There are many ways of exposing APIs (JAR files or RMI in Java, .net Assemblies, COM objects, DLL and .H files in C/C++, JSON over HTTP, XML over HTTP, many home-made methods).
Web Services are just yet another way of exposing API, in this case the actual execution of the exposed methods is done not on your computer, but on some other computer on the Internet (on the Web - hence name "WebServices").
A web service can be thought of as a type of API. But for the moment, you should forget that, and just concentrate on learning what an API actually is; a precise definition of methods for interacting with a piece of software. Sometimes, this involved sending data over a network, but usually we're talking about functions that may be called from a program.
For example, there's a function called FileUtils.rm in Ruby. This is the API; when you're calling the function from a Ruby script, it always looks the same. Then there's the implementation of the API; that's the code that actually removes the file - it might look completely different in every implementation of Ruby, but you (normally) don't care about that, since you're only dealing with the Ruby API.
Webservices available over internet.you can get information without actually having the classes or know how it works using http and soap protocols.
API is a kind of library (set of classes), you can use the functions available in that to perform some action in your application.
Check out the wikipedia entry on web API's at http://en.wikipedia.org/wiki/Api#Web_APIs.
It's well written, though pretty much agrees with what the others here say.
APIs exposed over web are Webservices
Related
I have a simple Java application (Not a web application) and using maven I distribute it through a Jar file. I need to expose some of its public methods through HTTP(Similar to rest APIs) so that other applications can reuse it by making rest calls.
Doing some research I see for example, Jersey is an option but that seems to be only available for Java Web applications. I also came across HTTPComponents + HTTPClient but the code is much more complicated than how Jersey is.
My question is whether there is a simple solution for Java applications to expose public methods through HTTP.
Thank you,
Sara
Please refer to the comments for the answer. Multiple Web technologies were suggested and seems like I have to convert the project to Web based application if we'd like to distribute as rest APIs and otherwise, if user agrees just use the Jar and Java APIs. Thanks.
I am trying to consume a public Web Service:
The Web Service uses SOAP communication
The Web Service doesn't expose the WSDL. It is possible to download it from the creator's website.
The Web Service only allows to connect via "whitelisted" static IPs.
The Web Service is hosted on GlassFish, so I am guessing it is written in Java.
The Web Service specification is rather long and contains many mandatory fields.
I would like to expose the Web Service to different type of developers during a Hackathon challenge, which may be using Python, Java, C# or other programming languages.
I used SOAPUI to test the Web Services and it was rather easy.
When I tried to use the standard packages in Python (SOAPpy) and C#, I had many difficulties. When using Java and CXF, it was a nightmare creating the request object.
How would you go about exposing the Web Service in a way which is friendly to developers?
No changes can be made to the original Web Services.
Thanks in advance!
If you want to access the original web service I recommend use its native protocol (SOAP) even though SOAP can be a major PITA and sometimes library support might be lacking (especially in modern script languages like Python, Ruby) because SOAP is not "cool".
ReST/JSON web services are deemed to be more "easy to work with" by many developers but shoehorning a "wrapper"/proxy on top of the existing web service will probably cause even more confusion and subtle bugs.
If the web service is fairly complicated this could mean this project is not ideal for a hackathon. If I were in your position I'd prepare client stubs (including a simplified library API) for 1-2 languages like Python and Java. For Python check out one of jurko-suds, pysimplesoap, or soapfish and check out which one works best out of the box with your service.
As I feel I'm drifting out of the StackOverflow scope I'll stop here :-)
Am I confused as to what is possible between an Android Client and Google App Engine? I would like to be able to create a Python API that would handle requests between GAE services such as Datastore, and an Android Client.
I have found some examples that detail how to make a call from within an Android Client, but it doesn't seem to outline whether or not you can pass data to any specific API language. The question I have is whether or not it is possible to use a Python API deployed on GAE and making calls through Google End Points, or would I have to use Java Servlets to handle requests?
Yes, you can use Python to do what you want.
Google designs their services (such as GAE and endpoints) to be language agnostic, e.g. using JSON to serialize objects.
There are a few advantages to using Java on both, such as being able to share code between client and service projects, but Google does not promote such dependencies at all - you will have no problem using Python instead.
Web services are used to share the services provided by an application, to outside world. This is my basic understanding of web services.
Suppose my application is to expose some specific behaviors and I have written the code for it and exposed the methods. The ones who want to use it can take the link to the wsdl, generate stub and call the methods.
What is the use of doing all this, when I can myself expose the methods, generate a jar and bundle everything in it and share the server address,jar.
How differently is web services important, when compared to a case explained above. Am asking such a general question due to unsuccessful search in many websites.
If you'd generate a client jar, whoever wants to use that would have to deal with Java. If you expose a Web Service instead, the user can use whatever technology he/she wants to use (e.g. Python, Ruby, .net, C, C++ etc. etc.). That would be a huge advantage.
Web service use a series of standards(SOAP, WSDL...) to make different kinds of system work together, certainly you can generate client jar as you like, but that requires your service consumer to learn how to play with it, so it's not a generic solution.
What you are suggesting is quite close to RESTful webservices. Unlike SOAP webservices, RESTful webservices do not require any WSDL files. All that you need to do is to issue a request to a particular URL.
As you explained correctly (in my opinion) SOAP webservices involve some more work which needs to be done, thus making them more complex, if you will, to integrate with other systems. This is not the case with RESTful webservices.
EDIT: You can check out a tutorial here. I have tried it myself a while back and it is enough to get you started.
I'm currently working on implementing the public API of our web application. The application is written in Java.
This is a financial application deployed on Tomcat. My users can manage their sales, customers, purchases, inventory, etc. It's a pretty huge application. The font-end is written in Java/GWT. The backend is written in Java s well. We use the GWT-RPC mechanism between.
What we want is to provide a way to access the financial data (read + write) via a public API. This way, developers will be able to better integrate their application (like a payroll application).
We don't use any framework. No Spring, grails, whatever. Also, no Hibernate, JPA, etc. It's a pretty old app, with lot of proprietary code for the ORM, XML-> javabean. authentication, etc. Cannot change all of that as the application is already in production and it just works that way.
The API infrastructure will be on a different sub-domain and on a different server.
The API should use Oauth to authenticate the users.
I looked into Grails, Play!Framework and Restlet to achieve my goals
Does anyone have some thought on them? Am I going in the wrong way with those frameworks? Is there another framework to look at?
Thank you all
I'd recommend following the example of Amazon and such and expose that API as web services, without regard for UI. Your have a further choice about SOAP versus REST. I think you'll find that REST will be simpler for your clients, because they only need to know about HTTP.
This doesn't mandate the use of any frameworks if you choose not to. The back end will work regardless of whether or not you use Spring, Hibernate, Grails, etc.
You'd have to rework the application you have to call the services if you wanted true reuse, but it might be worth it in the long run. Both your UI and clients would be using a common back end API that way.
I have some thoughts yes. Financial applications tend not to use OAuth. To be clear: nobody with vulnerable data uses OAuth. That includes privacy, medical and financial data.
What kinds of deployment environments do you expect to use this API. That might narrow it down, the standard answer if you have absolutely no idea who your client is, is still supposedly SOAP (since so many people know and accept the buzzword).
If you're going to expose read/write to a Java-based financial services application over the public internet, I would look at SOAP-based web services with JAX-WS as there is a pretty mature security spec in WSS and the API is relatively easy to use and may not require much in the way of changes to your existing app.
REST is perceived as easier in general but for this type of application you might find your target audience is more familiar with SOAP anyway. All depends who your target audience is and exactly what you're trying to achieve, but worth considering.