What is a Web Service?

This is a case where perhaps an image is worth a thousand words. For example, we'll use a site like pt.stackoverflow.com.

You can imagine the structure as follows:

  

Atypicalwebapplicationwithclientandserverlayers.Thebackendcanbedividedintoseveralotherlayers:Intheexampleabove,endpointsandAPI   makeupthewebservicelayerorwebserviceswhichtogetherwithbusinessrulesformtheapplicationasawhole.

Yourbrowser(theserviceclient)contactstheapplicationserver.Muchofthecontentisstatic,andcanbeservedviasimpleHTTPservice(images,javascriptfiles,css,andsoon.)

However,featuresliketheupvoteofyourquestionneedtointeractwiththedatabase.Thesebehaviorsaredescribedinthesite'sbusinessrules;andwebservicesexisttoallowthebrowsertointeractwiththeserules.

Describedinthisway,webservicesserveasaninterfacebetweentheclient(inthiscaseabrowser)andtheinternalstructureofanapplication(inthiscasebusinessrules.)

Anexampleisupvote:WhenIvotedpositivelyonyourquestion,thefollowingendpointwasaccessed:

link

This endpoint belongs to a webservice that received the action. The site's business rules, in turn, propagated the notification: Multiple users received a message like 'Hey, now show 7 votes instead of 6.'

This explanation is simple, and is meant to give you an initial understanding of how the concept works. If you want to go deeper, here are some resources:

Message specifications: SOAP , REST ; differences between these types .

Data specs: JSON , XML

My concept of Web Service is:

An application (I'll call it API ) that receives parameters and executes instructions, for example a registration. An application receives the parameters " email " and " password ", registers in a database, and returns a success or failure response in JSON or XML .

Another application (I'll call the client) wants to register users in this "", then it sends parameters by JSON or XML case " email " and " password ") and get the success or failure response.

In summary, my point of view is that a web service consists of an application being able to receive data from anywhere (provided in the format that it can interpret), process that data and send the response to the requester.

An example I'm developing:

I have a web client registration system, which has a module that I call API, where it receives parameters like $ name , $ email and $ password , inserts them in the database and returns the response in JSON with success or failure of the insertion.

Another web module makes the requests, sending the $ name , $ email and $ password parameters to this api, and obtains the answers. Another module, this time an Android application makes the same requests, sending $ name , $ email and $ password and receiving the responses. The advantage of this is a central application, able to process information and be consumed by several different applications.

It would be the "middle of the field" between two systems, I will give you a very simple system to see if you understand.

You have a system that we'll call 01 where the information is. You also have a system that we will call 02 where you want to have the system information 01.

To facilitate this transport of information between the two systems, it is possible to develop a third system that will communicate with the other two, so the 01 calls the web service and sends him "I want to import clients".

Web services will pick up the "customers" and will send them to 02 "Insert this data into the customer table".

It would be more or less in that sense that it works.

A common web application, the browser launches a request (request) to the server, then the server (which is waiting for requests) returns information (after processing or not) to the browser. This information is in HTML that the browser uses to draw the web page.

A webservice application works similarly, but does not return HTML but data only. Usually this data is in XML or JSON format but can be any other format.

A practical application for this would be a mobile app. You do not want to download the entire page as this would take a lot of data and not consume a browser that has to "draw" the screen when it is received. In a mobile application, the screens (interface) is ready (only display) and only the data is exchanged which saves the data plane and gives more speed because the amount of data is smaller and does not have to "draw" the screen every time.

I cited the example of the mobile app, but nothing prevents other types of applications from using webservice, for example an electronic invoice application sends notes and queries the situation through SEFAZ webservice.

TL; DR : Webservices allow two (or more) machines to communicate over a network.

For a deeper explanation, imagine the following scenario: Your company trades dollar-denominated products whose value fluctuates daily. It is extremely important that you have these values updated so that you make decisions that bring you the best results. You can hire a trainee to update these values manually, or you can consume a service to provide this information automatically and reliably.

This service is the same as webservice . You ask a question (how many five dollars are worth a dollar today?), And he responds. This process, at the communication level, occurs through requests based on the HTTP protocol . There is an endpoint on a server that is always waiting for the question, and if it is done correctly, it responds. In a quick search on google, I found a webservice that perfectly illustrates the case of dollar (and virtually all currencies) quotation, which can be accessed here .

The question (or request) must be made correctly, otherwise webservice will not be able to understand the request. In the case of the quote, the question should contain the two currencies you want to convert, right? Using the webservice linked above, I made the following request (in cool terms, I entered this site):

  

link

and the response was XML in format

<double xmlns="http://www.webserviceX.NET/">3.9818</double>

That is, through a GET request (the parameters are explicit in the URL), I got the information I wanted within XML . How did I know which parameters to use or, in other words, what is the correct format of the question? In this specific case, who provided the service also provided the parameters it is waiting for the desired information to be reached. Try the requisition

  

link

to see what happens.

The GET request is one of the four standard HTTP protocol requests . The others are POST , PUT and DELETE . I will not go into details of how they all work, but you can read about the HTTP protocol here .

XML (which is the return format) is a markup language that allows you to manipulate the data (or data) with ease. In PHP , the simplexml_load_file() method allows you to read XML , extract the data and do with them whatever you want. To make a .php file talk to another, you could use the cURL (which is giving me a beating this week). There is also the endless Ajax , which allows you to consume services asynchronously. I particularly prefer to use the JSON format for responses, because most applications that consume my services are written with AngularJS .

There are some standardizations for services, in the sense of how questions and answers should be asked and constructed. At the webservices wiki , you can find a number of types of services that are based on markup languages.

You may also come across the term RESTful APIs, which are basically services that are based on the REST architecture . The services I build are always based on that model. There is also this great story that explains how that architecture works.

For the icing on the cake, and for the sake of curiosity, WordPress is deploying a RESTful API named WP API , which goes basically allow to make any instance of WP in a webservice. A hand in the wheel, in my opinion. =)

Practical example

Imagine the following situation. A company has an ERP full of complex rules and routines. Now imagine the following situation. This company saw the need to integrate it with a third party system. In this third system is expert in managing workflows. One such is the purchase of pens. However, in the end, it's no use to approve if you can not generate this purchase in ERP.

Webservice

Well, here comes the WebService. This guy provides a bridge between systems. In this company context, the ERP will have a service provider. This provider has a file with all definitions of the methods of each service. For example, a purchasing service might have the methods checkPurchase, Purchase, Exclude, Purchase, among others. For this file is given the name of wsdl.

Advantages

The great advantage of using this form of integration (which is not the only one) is to ensure that all information that goes out and enters the ERP goes through all the business rules, not to mention information security. Since the methods generally receive some form of authentication as user / password or token. In addition, if ERP evolves, the third system does not necessarily need to be tuned.

How does it work?

Data exchange between systems basically works using Http and XML / Json protocols. Where at the time of sending something called SOAP envelope is mounted and after it is sent to the recipient. This envelope has some data in its header, such as the address (ip / host, port) of the recipient. In the body of the envelope, the request data will be sent. In the example mentioned would be the pen purchase data.

What else?

In addition, webservice is also known as a form of multi-language or cross-platform integration. Since you can have, for example, an application made in java and one made in C #, both tips can communicate without problems using WS technology.