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 :)
Related
I have a situation where two components are being designed that have some similar presentation requirements, but have been built using different technology stacks (one is java and the other is .net). For one feature, the developers are propsing using a web service that returns HTML so that both components can re-use the same display logic. I have been told that it is a bad practice to use a web service in this fashion, and that a web service should focus only on data.
In terms of web-service or SOA best practrices, should you return HTML from a web service?
If it's actually a web service (i.e. meant to be called by scripts), HTML is a bad idea, as you'll have a difficult time handling error situations.
A well-designed XML or JSON answer is probably the way to go these days.
I know, WCF Service is better then ASP.NET Web Service due to (a lot of reasons). But is it reasonable to use WCF service if everything you need is to have 3 simple methods, each of them with 2-3 parameters?
For me it seems like firing on birds with cannon.
Thanks a lot!
That a framework has features you don't need isn't a great reason not to use it. WCF will work great for a simple service of just a couple methods, and you'll have the flexibility of protocol bindings, extensibility, security, etc. there if you ever need it. That said, the 3.0 version of WCF did require a lot of intellectual overhead to get started; the team is working to reduce this and make it as easy as asmx to get started. If you can, use 4.0.
There are quite a few opinions out there on this. The most common theme that I come across is to your point, simple job/simple service. That being said I think it is pretty quick and easy to throw together a WCF service and have been converting any of our legacy ASMX services to WCF as they need updating, even the smaller ones.
I thought to practice SOAP API. I know it is a time for REST but I thought to give a try to SOAP. I somehow got Flickr.com API supporting SOAP but it has very difficult documentation. No, working examples are available.
Q1. So, do anyone know where I can learn SOAP. Do anyone has SOAP working example for Flickr API
Q2. Any service other than Flickr providing SOAP interface. I saw Google search api has closed new request for SOAP.
regards
SOAP has been largely superseded by REST on the public Internet - as you have noted in your question and has been alluded to in comments.
There are still large users in the Intranet context, companies with an installed base of SOAP, Service Bus, and other concepts that you may well come across if you end up working at one of them. (There are still CORBA users out there also!) When you control both ends of the application, you may have less reason to be flexible using REST.
So if you are looking for useful public implementations you are mostly out of luck.
That said: do create your own services and try them out on your own. Define a service and implement it. Create a client in a different language. Create another client in a third language.
If you are looking for an educational experience, this will lead you down some of the same paths that has lead to REST use in wide-scale disparate systems (and may also shed light on why the public/private has split the way it has)
Good Luck
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.
I'm beginning a project right now that will require a pretty extensive web back end. Of the different calling conventions, we have found that the easier and more cost effective approach is to build a standard SOAP web service.
So now, we are in the process of looking at the different web service frameworks in order to determine which will meet the business needs:
Security
Cost
Time
I've only worked with WCF, which I was fairly content with, but I would like to explore all other options before I make a definite decision. In your experience, what do you feel is the best web service framework?
Web Services Interoperability Technology (Java)?
WCF (.NET)?
ActionWebService (Ruby)?
On a side note, we need a framework that can securely be accessed via iPhones, Windows Mobile Devices, and Blackberries.
Thanks in advance for your help.
Chris
WCF can be used to make both SOAP and RESTful Web Services. Interoperability is guaranteed as long as you stick to standards. But the more standards you put on it, less platform can catch up. In that sense REST on Basic Auth over https would be very light weight. Also see WS-I Basic Profile. Java vs .NET would be matter of taste, I think. WCF is not perfect, but it mostly seems to do the job.
One thing to consider about WCF is that it has a very rich extensibility model. Anything it doesn't do out of the box, you can teach it to do, with little or no change to your basic service.