This will sound naive (but then I am a junior programmer), but if I write a web service say in Python (standard WSDL web service), I then need to host it so it is reachable from an end point.
This will give a URI for the service and then from another language, say Java or VB.NET (any), I can add a web service (this one) and then call the web service's object model, correct?
Thanks
if I write a web service say in Python (standard WSDL web service), I then need to host it so it is reachable from an end point.
By definition, a web service need to be exposed through HTTP i.e. "hosted" (by the way, WSDL is a language to describe a web service).
then from another language, say Java or VB.NET (any), I can add a web service (this one) and then call the web service's object model, correct?
Without entering in the details, web services are basically web APIs accessed via HTTP. So yes, you will be able to call a web service from any language than can make HTTP requests (not sure what you mean by "add a web service" though).
If you are expecting a more precise answer, feel free to ask a more precise question :)
Related
I have searched a lot upon internet but still i didn't get the clear difference between web services and web APIs? Somewhere I read that all web services are API's but all API' are not web services. How?
What all I know is both allow to utilize the functionality of other applications.Can someone describe me clear difference?
I have been on the same journey to learn the differnce between Web API (not JUST API) vs Web Services.
First, we know for a fact that both use the Web as the communication tool as stated by #Kris.
While looking at these 2 videos, both serve as the "middleman" (the waiter in the restaurant) for a client to ask a Web Server to process and deliver a response.
Web Service (From 0:35)
API (In general) (From 1:12)
When I was looking for an actual differnce between the two, usually most articles and videos go on an unrelated comparison between "Web Services vs API" as they exclude the "Web" out of "Web API".
See this article, for example, which contains the title "Web API Vs Web Service...." yet, contain sub-titles like:
"Differences of API vs Web Service"
"Pros and Cons of Web Services vs API Service"
"Web Service vs API: Fueling Both With Scraping Robot’s API"
The only difference I could find is if we were to discuss this in .NET context.
Here's a question post related to this.
To sum it up, Web Services are used in the SOAP protocal while Web API is usually created in the RESTful way. The more detailed answers are in the post but ultimatelly do not answer the main question that is asked.
Conclusion: The question raised in the public domanin has no clear definition to what is difference between the two, thus the 2 terms are ,for the most part,
interchangeable
All web services are APIs. An API is an Application Programming Interface. But there are offline APIs, which are not web services. There are APIs for all things from Office to Websites. The API is just a defined interface to be able to control/communicate with some software. Web Services just provide that means of connecting over the web.
There is more to discuss when you are talking about APIs which are communication protocols and data formats, but you get the basic idea.
An API (Application Program Interface) is the interface through which another program can communicate with a program.
A web service in this context is one of those programs with an API. 'Web' means that it is accessible via the web, mostly via HTTP. A service usually has a well defined purpose.
For instance a date web service's purpose could be to provide the current date. The API of my service would have a single 'endpoint': get the date. The service then implements this API. It somehow retrieves the date and sends it back.
What does a Web service really mean ? I am not looking for a theoretical explanation, I am looking for something practical.
I was thinking that anything I can call from an external client is a Web service, so a basic PHP which returns JSON data could be a Web service.
But then I started reading about Web services in W3Schools.org and I got confused. If the PHP URL which returns JSON data is a web service, why would I need to do SOAP, WDSL etc ... to create a Web service. Isn't it extra work?
Also, if SOAP is the way data is sent back and forth, what about other transport types?
What differentiates a RESTful Web service from a SOAP based web service?
When you are talking about a webservice people generally misunderstand what it means, a webservice is simply a way to interact between a and b that abstracts the use of local technology standards. A WSDL defines the way in which the SOAP message is being sent over the channel. REST uses JSON over HTTP, WSDL uses SOAP over HTTP.
The advantage of a webservice is, say you develop one piece of code in .net and you wish to use JAVA to consume this code. You can interact directly with the abstracted layer and are unaware of what technology was used to develop the code.
SOA is a set of design paradigms and standards that tell you how to develop your services, in SOA each service is meant to comply with the principles listed below. WSDL is generally linked with but not essential for a SOA solution. If you wish to learn about SOA google "Thomas Erl SOA".
Priciples of SOA
Standardized service contract
Service loose coupling
Service abstraction
Service reusability
Service autonomy
Service statelessness
Service discoverability
Service composability
This Q&A Restful vs Other Web Services brings a lot of light to what is a webserver, and differences from SOAP and REST. Id recommend to read all the answers (many of them are very good).
I'm learning about web services and most of the resources I've been reading talk about registering your web service once it's ready for use by others. Is registering a web service required to use the service?
For example, let's say I have a web application on a company intranet and I create another web service app that retrieves some sort of useful information to be displayed on this private intranet site. Would this new web service require being registered just so my web app can use it or can the web app simply interface directly to the new web service (following the WSDL file) without the need of some sort of UDDI registry?
You can certainly use the service without the UDDI registry.
I have created several Web Services and have immediately used them without registering them. Registration gives others confidence that your Web Service is legitimate and descriptions of how to interact with those services.
Imagine doing development where you have to register any Web Service before using it. Yikes!
No, not at all.
You are probably talking about API directories you may register your WS at. Like UDDI or what it’s named. Entirely optional.
Nobody uses UDDI anymore. It's an idea whose time has come and gone.
It was thought that there would be public registries of web services that everyone would use to find a web service to meet their needs. That never happened.
How could either the service or the app know whether or not the service was registered?
Furthermore, why would they care?
If you're trying to use service orientation the right way, your web services should be registered within a service registry. The registry should contain the published contract of the services and any meta-data that helps the discovery process.
A different questions is: does a service consumer program need to look up a registry and dynamically bind the service it needs to call? NO, NOT AT ALL.
But then, what discovery process am I talking about?
I'm referring to a human (developer, architect, etc.) who is designing/developing a program that needs to call a service. This person should have means to search what services are available in his/her organization. If not, the benefit of reusing services is compromised.
Discovery is also about humans finding out there's a service somewhere in the IT organization that offers the functionality they want.
In this case, the registry can be as simple as an html report that is created and updated manually or generated by parsing (xslt comes handy) the wsdl files.
I am looking for some good starting point for developing web-service.
I have one application which has C++ library support using which I can get all the details of the product.
I am supposed to write web service SDK for the same.
Any help.
Web services generally refer to a technique that allows code to be called via HTTP requests and responses. This is similar to a web page, except that what is returned from a web service is usually not HTML intended to be displayed in a browser - it is usually data of some kind.
"Web Service" is one of those terms that means whatever the person saying it means. Basically, its just a way to access data or functionality via http. There's a few standardized methods - REST, SOAP for web services, or you can just serve up XML, JSON, or other data from a plain old server side web app.
What you'd want to do is investigate what form this Web Server you are supposed to write needs to be in (SOAP, REST, something else), and then go from there.
What is the difference between using a "Web Service" and calling a server page such as JSP/ASPX?
To me it looks like a Web Service is just a framework around the server pages. For e.g. I can have a JSP page that takes:
mypage.jsp?method=getupdate¶m1=23¶m=44
(I can also send these variables through POST)
In my JSP page I can call the appropriate method based on the value of "method" and return a value back to the caller client app. Is this the raw form how a Web Service actually works? OR is there more to a Web Service call like someone told me that when you call a page, it is rendered but a Web Service is not rendered. But What if I remove the HTML code from JSP page then?
So when we say XML Web Service, the difference is that the client and the server both wrap/unwrap the requests/responses using XML and POST it to the Web Service page.
Web Services are a well defined set of standards defined by the W3C and other relevant bodies, which mostly define an architecture that runs over a network to communicate diverse applications while ensuring interoperability, discoverability and some other relevant criteria.
You can certainly create a server page just for your application without SOAP or XML-RPC. It's just that you shouldn't call it a "Web Service" unless it outputs SOAP or XML-RPC and provides a WSDL description for itself, because that leads to confusion and show you don't know what the "standard Web Services" mean.
You are correct to say that web services are a layer on top of the server pages. One of the common types of web services are SOAP web services that wrap requests and response into XML to achieve interoperability between different platforms/frameworks.
Sites like Facebook and Flickr that have much the same kind of public APIs are calling them 'web services' and I don't see that you're doing anything different.
Vinko seems to have some objection to polluting the 'Web Service' moniker but there's plenty of room under the W3 definition of a web service to include what you're doing.
As for Web services having to output SOAP or XML and provide a WSDL? I think there's a few REST advocates that would argue that point.