I am little bit confused about what really a web service is. You say Amazone web services,etc like that, they offer information. So what is the requirement to be a web url to be a web service ? Let's say I am not much familiar with web development, how could you explain it to me ? But I can get it if you point some ways.
And also little about SOAP and REST basically for someone really new
What is a web service
It is many things. In programming, in generally refers to a web page, that can be called from an application (be it another web page, or desktop app), and the caller will pass in data to it, or receive data from it.
In this sense, it's basically like a 'method' or 'function' in a normal programming language; except you're calling it over the internet.
SOAP
A message format. As discussed above, a web service is a basically a 'method' or 'function'. SOAP is the 'instructions' and 'data' to this method. It will outline data types, and possibly a bunch of data as well. It is an XML format.
REST
REST is the means of implementing an interface to your application but, implementing access control, and other such things, specifically with HTTP Response codes. So you will get a 401: Denied (I think that's the right code), if you don't have access. There are other types of response codes that are useful. It also makes use of other HTTP commands like PUT/HEAD/OPTIONS.
The W3C defines a Web Service as (quoting) :
A Web service is a software system
designed to support interoperable
machine-to-machine interaction over a
network. It has an interface described
in a machine-processable format
(specifically WSDL). Other systems
interact with the Web service in a
manner prescribed by its description
using SOAP-messages, typically
conveyed using HTTP with an XML
serialization in conjunction with
other Web-related standards.
That definition is maybe a bit too restrictive, considering how that term is used nowadays -- I'd probably go with just the first part of that definition, which is quite generalist :
A Web service is a software system
designed to support interoperable
machine-to-machine interaction over a
network.
Wikipedia also has some interesting definitions, like :
In common usage the term refers to
clients and servers that communicate
over the Hypertext Transfer Protocol
(HTTP) protocol used on the Web.
From what I've seen :
A couple of years ago, when we said "web service", we generally meant "SOAP, WSDL, ..."
Now, when we say "web service", we often mean "whatever allows to call something on another server, be it SOAP, REST, ..."
A Web-Service can be considered as a set of methods that enables communication amongst applications irrespective of the application's coding language or framework.
http://acharyashri.com/blog/WebServices.html
Think of Web services as remote APIs (since they are basically just that). You have a method that you want to implement. Let's suppose the method wasn't built by you and resides somewhere else in the world on equipment that you have no control over—how can you go about providing that remote method what it needs in order to get instantiated?
When you find a Web service that you want to include in your application, you must first figure out how to supply the Web service with the parameters it needs in order for it to work. That need also extends a bit further. Even if you know the parameters and types that are required for instantiation, you also need to understand the types that are passed to your application in return. Without these pieces of information, using Web services would prove rather difficult.
Just as there are standard ways to represent data as well as standard ways to move this data over the Internet using Web services, there is a standard way to get a description of the Web service you are interested in consuming. Web Services Description Language (WSDL) is a specification of XML that describes the Web services you are interested in consuming. It's just an interface to describe a web service.
Related
Is REST the future for SOA:
SOA architectural style is based on a functional decomposition of
enterprise business architecture and introduces two high-level
abstractions: enterprise business services and business processes...
REST, on another hand, is a set of architectural guidelines expressed
as Resource-Oriented Architecture (ROA). ROA is based upon the concept of resources;
... it is impossible to build an SOA system using true REST.
and
The REST Web Service approach is an approach for using REST purely as
a communication technology to build SOA. In this case, services are
defined using SOA style decomposition and REST-based Web Services
are leveraged as a transport.
Could you pls explain in more details the last quote? Did they mean RESTful Web Services is smth different from REST or not only a REST or what? What did they mean by use REST as a communication technology? What did they mean by "REST-based Web Services are leveraged as a transport"?
Update: for tonicsoft answer
Due you can't build SOA with pure REST (like sentence with pure nouns) I'm wondering what is the right way of arranging app parts where REST is appropriate and where isn't? Should I separate REST-part from not-REST parts? How not-REST part should comunicate among each other and with REST parts?
Yes, the article is stating that REST is something different to "RESTful web services".
The author compares REST to "nouns" as opposed to verbs, or the "DBMS" of the web. Can I write a sentence without using verbs? No. Can I build a system using only a DBMS? No. In the same way, one cannot build a system only using REST architecture principles. In most systems REST semantics break down eventually. One example given in the article is when a messaging solution is required.
I think the author is saying the a "RESTful web service" is the whole sentence whereas REST is just the nouns. In a "RESTful web service", the parts of the system which do not have REST semantics (basically anything that is not CRUD) can be implemented using similar technologies and programming styles often found in the implementation of pure REST components.
"REST as a communications technology" basically just means restricting the transport implementation of the service to HTTP. Most web services frameworks provide multiple options for the transport (e.g. WCF can do SOAP over HTTP, or use shared memory, or TCP for networked services without HTTP). REST shuns this flexibility in favour of simplicity. A "RESTful web service" will be purely HTTP based, according to my interpretation of the quoted article.
In summary, REST is simply an architectural style. It is impossible to build any technology solution of note using only one architectural style. Therefore a "RESTful web service" is simple a web service that leverages the REST architectural principles where appropriate.
Again, this is not my opinion, it is simply my interpretation of what the article is saying.
How to seperate pure REST operations from the rest of your "RESTful web service"
I don't think any particular seperation is needed between the pure "REST" endpoints (CRUD) and the more behavioural/service oriented endpoints, beyond the fact that any given URL should be either one or the other, and you may find that you don't want to mix the two styles under the same base URL. For example, if you have a REST endpoint for retrieving the details of a user account with id=1234:
/users/id/1234
and you want to implement a "verify email" workflow (which for argument's sake is not implemented as a REST service), then choose a URL for your verify email workflow/service that doesn't clash with the REST style /users/ API. Don't be tempted to do things like this:
/users/id/1234/verifyEmail?securityToken=XXXX
but instead, prefer to create a completely new URL for this endpoint:
/verifyEmail/userId/1234?securityToken=XXX
These guidelines are largely arbitrary: the important thing is to design your service in a way that will make sense other programmers, as these are the people who will use your service. As with any other bit of software design, Single Responsibility Principal will get you a long way. Each base URL should only do one thing!
As mentioned in th e introduction, the H ypermedia as the E
ngine of A pplication S tate (HATEOAS) constraint is one of
the least understood constraints, and thus seldom implemented
correctly. Annoyed by the fact that a lot of services claim
to be RESTful regardless of violating the hypermedia
constraint, Fielding [29] made it very clear that hypermedia is
a fundamental requirement but since the term REST is so widely
misused, there are e fforts in the community to look for an
alternative term, such as Hypermedia API , to denote truly
RESTful services
http://www.ws-rest.org/2012/proc/a4-2-lanthaler.pdf
http://www.markus-lanthaler.com/research/third-generation-web-apis-bridging-the-gap-between-rest-and-linked-data.pdf
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
The REST architecture has well defined constraints you can find here: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
The term RESTful comes from the Richardson Maturity Model as far as I know. http://martinfowler.com/articles/richardsonMaturityModel.html I don't know where the original article is, but as far as I know it is some nonsense, something like you should call every API REST, which fulfills at least a single constraint and you should call RESTful only those APIs which fulfill every REST constraint. Fielding made clear many times that only APIs which fulfill all constraints are considered REST and APIs which don't are simple web APIs, but not REST APIs. Sadly both REST and RESTful words are overused by developers who know nothing about REST. Most of them don't even know that REST constraints exists. For them REST is only CRUD and URI design. Just check SO questions about REST, 99% is that kind of stuff. Even funnier that I get minus points from them when I answer questions related to REST... So to avoid confusion and misunderstandings we build Hypermedia APIs now, so we can live in piece as long as people do not start to use this word as well...
I cannot make sense from most of the questions. I compared REST and SOAP here along with many people Representational state transfer (REST) and Simple Object Access Protocol (SOAP) maybe you find an answer to your questions.
How not-REST part should comunicate among each other and with REST
parts?
If you mean microservices by app parts, then ofc. SOA and REST microservices can communicate with each-other simply by sending HTTP and SOAP messages to each-other. If you don't have a legacy SOAP system, then I recommend to develop only REST services, since SOAP is stateful, and so it does not scale as well as REST.
This might be a silly question on this site, but I want to learn more about it.
Being in the Software Engineering field, I have come to know that it's useful to get acquainted with Web-Services. I am trying to understand it. To do so, I must know the difference between a Web-Service and a Application-Service in simple terms.
I have heard about SOAP & REST Services.
For a newbie like me, its overwhelming to understand these concepts when I search them in Google.
How to understand these things better and in what order?
I think it's a great and simple question which usually confuses most of developers. What is Application Service and what is web Service?
Web service is a common term which you can find easily on the internet. Although some time they cross each others boundaries but here is a simplest explanation I can think of:
Application service or Application Layer is an abstraction layer reserved for communications protocols and methods designed for process-to-process communications. Application layer protocols use the underlying transport layer protocols to establish host-to-host connections.
Some time you can also use Application Service to define method calls within your application.
WebService: Any application or method which can be accessed by web is a Webservice. You can also say: anything available on the web is WebService.
There are three common web service architectures:
RESTful resource-oriented,
RPC-style e.g. SOAP
REST-RPC hybrid. 90% of the web sites use this unknowingly e.g. http://mysite.com/get/pictures?tag=birthday :)
I was trying to put the difference between websites and web services (irrespective of RPC based or RESTful) development in words. Am I right is saying when a client is another software (assuming browser is just a tool for the original client) and producer is responding in XML (assuming this is the standard for data transportation) comes under web services (programmable web) otherwise its a website for humans?
Thanks
-Abidi
Yes. One could further precise that bots and crawlers are a secondary phenomenon where software attempts to mimic human behaviour. So that your high level distinction still stands.
The huge difference is that web sites have a double role
provide information
present information
Whereas for web services, there is no concept of presentation. You will find this same distinction in their respective expression languages: whereas HTML cumulates both information tagging and presentation directives, xml is only about information identification, organisation, transformation and organisation.
Historically XML followed in the wake of HTML when people figured out that there were better ways to access information exposed by web sites than just ripping their not well formed html pages more or less aping humans; whilst at the same time everybody knew that neither CORBA nor RPC could fill the need for B2B communication because of their unability to be routed through a WAN.
Hence then, SOAP, all the OASIS standards and only later REST services, still preferred for devices too 'light' to accommodate full fledged SOAP stacks.
Something like that. Of course the client calling the "web service" may be the browser itself. I'd say that the difference is that a web site returns content that is meant to be consumed by human beings while a web service returns content meant to be consumed by another program. In the latter case it doesn't have to be encoded as XML; it can be anything. It's tough to make a good distinction between "web site" and "web service" on the basis of the type of content returned, because there is plenty of content that can be consumed equally well by a human being and a program. A service might return a PDF of a customer statement, for example, and could be used directly by the customer and also by a bill-printing program.
Maybe a better definition is to say that a "web site" is a collection of "web services," some of which may return HTML pages and some of which may return other types of data.
I just asked a question about whether it was possible to write a web-page-checking code and run it from free web server, and one supporter answered and said that it was possible only if I run "a web service" as simple script won't do that. He also suggested that I used Google App Engine service. I wonder what does it mean to write a "web service" and how is it different from writing a script?
A web service essentially provides the capability of RPC (Remote Procedure Calling) on top of the protocol of the web (HTTP). A URL implements an API which accepts a set of function arguments and returns a value. Different approaches are used to implement this RPC mechanism on top of HTTP protocol. XML-RPC defines a simple mechanism to specify the arguments and response using XML. SOAP is a much advanced version of XML-RPC. JSON-RPC lets you specify the procedure arguments and return values using JSON (JavaScript Object Notation).
Several programming languages come with built-in support for developing and working with web services. For example in Python, xmlrpclib provides the client side functionality of XML-RPC protocol. The XmlRpcServer library in Python makes it very easy to develop an XML-RPC based web server. Web services are interoperable in the sense that the client and server can be easily implemented in different programming languages and they don't need to worry about the details of each other.
Web services are different from other RPC mechanisms like COM/CORBA/JAVA's RMI. These RPC mechanism use binary data for exchange of arguments and results. The web services uses text oriented protocols like XML/JSON to implement the RPC protocol. Hence they are heavier from the perspective of communication overhead. They are still very good for development of loosely coupled systems. One big advantage they have is the fact that they are not tied to a specific programming language.
By "web service" one normally refers to a service available through HTTP protocol. The protocol sitting on top of HTTP can vary (XML, SOAP, JSON etc.).
But of course one can "complicate" the definition at will :-)
This is example of web service: http://www.webservicex.net/CurrencyConvertor.asmx?op=ConversionRate
When you scroll down you will see you can supply two parameters and get result back. Webservices can support different methods of communication. You can communicate with it using XML, SOAP, or HTTP GET/POST.
So web-service is a special type of script which main function is to expose method to public use (you can set access permissions a well), perform calculations on server-side and return output.
My gut feel is that document based web services are preferred in practice - is this other peoples experience? Are they easier to support? (I noted that SharePoint uses Any for the "document type" in its WSDL interface, I guess that makes it Document based).
Also - are people offering both WSDL and Rest type services now for the same functionality? WSDL is popular for code generation, but for front ends like PHP and Rails they seem to prefer rest.
Document versus RPC is only a question if you are using SOAP Web Services which require a service description (WSDL). RESTful web services do not not use WSDL because the service can't be described by it, and the feeling is that REST is simpler and easier to understand. Some people have proposed WADL as a way to describe REST services.
Languages like Python, Ruby and PHP make it easier to work with REST. the WSDL is used to generate C# code (a web service proxy) that can be easily called from a static language. This happens when you add a Service Reference or Web Reference in Visual Studio.
Whether you provide SOAP or REST services depends on your user population. Whether the services are to be used over the internet or just inside your organization affects your choice. SOAP may have some features (WS-* standards) that work well for B2B or internal use, but suck for an internet service.
Document/literal versus RPC for SOAP services are described on this IBM DevelopWorks article. Document/literal is generally considered the best to use in terms of interoperability (Java to .NET etc). As to whether it is easier to support, that depends on your circumstances. My personal view is that people tend to make this stuff more complicated than it needs to be, and REST's simpler approach is superior.
As mentioned it is better to choose the Document Literal over RPC encoded whenever possible.
It is true that the old java libraries (Axis1, Glue and other prehistoric stuff) support only RPC encoded, however in today's most modern Java SOAP libs just does not support it (e.x. AXIS2, XFire, CXF).
Therefore try to expose RPC encoded service only if you know that you need to deal with a consumer that can not do better. But then again maybe just XML RPC could help for these legacy implementations.
BiranLy's answer is excellent. I would just like to add that document-vs-RPC can come down to implementation issues as well. We have found Microsoft to be Document-preferring, while our Java-based libraries were RPC-based. Whatever you choose, make sure you know what other potential clients will assume as well.