We are writing a SOAP client-server application in PHP. Simple Object Access Protocol (SOAP) - general description
SOAP (Simple Object Access Protocol) is a standardized protocol for transmitting messages between a client and a server. It is typically used in conjunction with HTTP(S), but can also work with other application layer protocols (such as SMTP and FTP).
SOAP testing from the point of view of testing techniques is no fundamentally different from working with other APIs, but it requires preliminary preparation(in terms of protocol theory) and special tools for testing. In this article, I would like to formulate a small checklist of necessary knowledge and skills, which will be equally useful both to a SOAP tester (who often has no idea what to grab hold of after setting the task) and to a manager who is forced to evaluate the knowledge of testers and develop plans for training.
Theoretical basis
The fact that SOAP is a protocol has great value for testing: you need to study the protocol itself, the “primary” standards and protocols on which it is based, as well as (as necessary) existing extensions.
XML
XML is a markup language similar to HTML. Any message sent/received via SOAP is an XML document in which the data is conveniently structured and easy to read, for example:
Don't forget to write an article!
You can learn more about XML at w3schools or codenet (in Russian). Be sure to pay attention to the description of namespaces (a method for resolving conflicts when describing elements in XML) - their use is required in SOAP.
XSD
When working, it is always convenient to have a standardized description of possible XML documents and check them for correct filling. For this there is XML Schema Definition (or XSD for short). The two main features of XSD for a tester are the description of data types and the imposition of restrictions on possible values. For example, the element from the previous example can be made optional and limited to 255 characters using XSD:
...
...
SOAP Extensions
In your work, you may also come across various “extensions” of SOAP - standards like WS-*. One of the most common is WS-Security, which allows you to work with encryption and electronic signatures. Often, WS-Policy is used along with it, with which you can manage the rights to use your service.
Example of using WS-Security:
All these extensions are enough complex designs, which are not used in every SOAP service; their detailed study At the initial stage of mastering SOAP testing, it is unlikely to be relevant.
Tools
As you already understand, SOAP is a serious matter; to work with it you need to know the theory and numerous standards. In practice, such complexity would lead to very significant labor costs (for example, you would have to look at the diagram in a notebook every time and send requests with curl). Therefore, tools have been created to make working with SOAP easier.
XML/XSD editors
A good tester begins testing at the stage of writing documentation, so it is convenient to use special editors to test circuits. The two most famous are Oxygen (cross-platform) and Altova (Windows only); both of them are paid. This is very powerful programs, which analysts actively use when describing services.
In my practice, three editor features turned out to be useful: XSD visualization, XML generation based on XSD, and XML validation based on XSD.
1. XSD visualization needed for a visual representation of the diagram, allowing you to quickly isolate required elements and attributes, as well as existing restrictions. For example, for a CheckTextRequest request, it is required text element, and all three attributes are optional (with the options attribute set to the default value of zero).
Visualization is necessary when there are many types and restrictions in the diagram. If you only need this and don't want to pay for special editors, then you can consider free alternatives (for example, JDeveloper).
2. XML generation XSD based useful when you want to see a valid example of a message. I use it to quickly experiment with possible message completions and test the nuances of how restrictions work.
3. After using the feature from point 2, it is useful to carry out XML validation against XSD– that is, check the message for correctness. Together, features 2 and 3 allow you to catch tricky defects in XSD even when the service itself is under development.
Testing Tool – SoapUI
SOAP testing almost always involves using SoapUI. You can read about using this tool in different sources(,), but it will be most effective to familiarize yourself with the official documentation. I identify 8 conditional levels of SoapUI proficiency:
Level 1 – I can send requests
Learn to create a project based on WSDL. SoapUI can generate all the necessary queries for you; All you have to do is check that they are filled out correctly and click the “Send” button. After developing the skills to create valid queries, you must master the art of creating incorrect queries, causing the appearance errors.
Level 2 – I can do Test Suites and Test Cases
Start doing mini-autotests. Test kits and test cases allow you to create scenarios API testing, prepare data for requests and automatically check the received response for compliance with the expected one. At first, they can be used simply as collections of queries. For example, if you have created a defect and want to quickly check it after fixing it, you can allocate a separate test kit specifically for defect requests.
Level 3 – I can write Assertions
After mastering test cases, it will be useful for you to learn how to make them automatically verifiable. After this, you will no longer need to look for information about the answer with your eyes: if there is an automatic check, cases will be marked green (if the check is passed) or red (if it is not passed). SoapUI provides a large set possible checks(assertions), but the most convenient and simple ones are Contains and Not Contains. With their help you can check the availability specific text in the response received. These checks also support regular expression searches.
Level 4 – use XPath and/or XQuery in Assertions
For those who are a little familiar with UI using Selenium, the XPath language is a familiar thing. Roughly speaking, XPath allows you to search for elements in an XML document. XQuery similar technology, which can use XPath internally; this language is much more powerful, it resembles SQL. Both of these languages can be used in Assertions. Checks with their help are more targeted and stable, so your cases will enjoy greater confidence.
Level 5 – I can write complex tests using special steps
Test cases can contain not only one request, but also several (for example, when you want to emulate the standard user scenario “create entity” → “export entity”). There may be other special steps between requests, for example:
- Properties and Property Transfer (help reuse data and transfer it between requests);
- JDBC Request (used to retrieve data from the database);
- Conditional Goto (allows you to make branches or loops in the test case);
- Run TestCase (helps to put some typical queries into separate test cases and call them where needed).
Level 6 – using Groovy scripts
SoapUI allows you to write Groovy scripts in a variety of places. The simplest case– this is data generation in the query itself using $(=) insertions. I use these inserts all the time:
- $(=new Date().format(“yyyy-MM-dd’T’HH:mm:ss”))– for insertion current date and time in the required format;
- $(=java.util.UUID.randomUUID())– to insert a correctly formed random GUID.
Full scripts can be used as steps in cases and checks. At some point, you will discover that several special steps from the fifth level can be replaced with one script.
Level 7 – using MockServices
WSDL-based SoapUI can generate Mock objects. A mock object is simplest simulation service. With the help of “mocks” you can start writing and debugging test cases even before the service is actually available for testing. They can also be used as “stubs” for temporarily unavailable services.
Level 8 – SoapUI God
Do you know the difference between paid and free versions SoapUI and use the SoapUI API in code. You use plugins and run cases through command line and/or CI. Your test cases are simple and easy to maintain. In general, you "ate the dog" on this instrument. I would love to talk to someone who has mastered SoapUI at this level. If you are one, sign up in the comments!
Testing with Programming Languages
Here's an example of what a request to the YandexSpeller API looks like, made using groovy-wslite:
import wslite.soap.*
def client = new SOAPClient("http://speller.yandex.net/services/spellservice?WSDL")
def response = client.send(SOAPAction: "http://speller.yandex.net/services/spellservice/checkText") (
body (
CheckTextRequest("lang": "ru", "xmlns":"http://speller.yandex.net/services/spellservice") (
text("error")
}
}
}
assert "error" == response.CheckTextResponse.SpellResult.error.s.text()
assert "1" == [email protected]()
As far as I know, there are no high-level frameworks (like Rest-assured) for SOAP testing yet, but an interesting tool has recently appeared - karate. With its help, you can describe cases for testing SOAP and REST in the form of scripts like Cucumber / Gherkin. For many testers, turning to karate will be ideal solution, because such scenarios, in terms of complexity of writing and supporting cases, will lie somewhere in the middle between using SoapUI and writing your own framework for testing SOAP.
Conclusion
It is unlikely that you will ever want to test SOAP just for yourself (as you might with REST). This is a heavyweight protocol that is used in serious enterprise solutions. But its heaviness is at the same time a gift to the tester: all the technologies used are standardized, and there are high-quality tools for work. All that is required from the tester is the desire to learn and use them.
Let's put together the same checklist of necessary skills for a tester. So, if you are just starting to test SOAP services, you need to know and be able to use:
- WSDL.
- SOAP.
- XML/XSD editors (at the XSD visualization level).
- SoapUI at level 1.
As you can see, the main emphasis is on learning the standards; in SoapUI it’s enough just to be able to perform queries. As you dive into SOAP testing You will be faced with tasks that will require more serious skills and knowledge, but you should not try to learn everything at once. Consistency in increasing the level of complexity of the tasks performed is much more important. By following this recommendation, one day you will realize that you have become good specialist in this area!
Simple Object Access Protocol (SOAP) is an XML-based protocol that defines the rules for transmitting messages over the Internet between various application systems. It is mainly used for remote procedure calls. SOAP was originally designed to function “above” HTTP (to simplify the integration of SOAP into Web applications), but now other transport protocols, such as SMTP, can also be used.
Let's say you're creating an application access service on the Internet; consumers interact with this service by providing it with information. Your servers process the data and return results to consumers. What is the best way to maintain communication with the system?
You could create a custom one client-server application and require consumers to use a special credential to access your service. client program. But if you are serious about finding yourself in the Internet business, you will have to create a client that runs on all possible client platforms - Windows, Macintosh, Unix, Linux, etc. In other words, you will need to write many different clients.
How would you feel about using the Web? This solution is, of course, quite acceptable, but is tightly tied to the browser implementation, and again you will have to create an infrastructure to send and receive incoming and outgoing information, as well as format and package the data for such exchange. For implementation complex applications you can choose Java or ActiveX, but then some users will refuse your services due to clearly inflated bandwidth requirements and inadequate security.
All that is required is a simple protocol that simplifies the packaging of application data and transfers it over the Web using content-adapted XML. By doing so, it ensures that both the sender and the recipient can easily interpret the content of any message. At the same time, thanks to the use of the HTTP Web protocol as a transport, it will be possible to eliminate the need to reduce the level of firewall protection.
The well-described Simple Object Access Protocol (SOAP) is a simple “glue” protocol that allows hosts to remotely invoke application objects and return results. SOAP offers minimum set conditions that allow an application to pass messages: the client can send a message to invoke a program object, and the server can return the results of that call.
SOAP is quite simple: messages are XML documents containing SOAP commands. Although SOAP can theoretically be tied to any transport protocol for applications, it is typically used in conjunction with HTTP.
Kennard Scribner, one of the authors of the book Understanding SOAP: The Authoritative Solution(Macmillan USA, 2000), says that SOAP works by converting the information needed to call a method (such as argument values and transaction identifiers) into XML format.
The data is encapsulated in HTTP or some other transport protocol and are transmitted to the recipient, which is usually the server. This server extracts the SOAP data from the packet, performs the required processing, and returns the results as a SOAP response.
Scribner noted that SOAP acts as a remote procedure call protocol, much like the Remote Method Invocation protocol in Java or the General Inter-ORB Protocol in CORBA.
Because HTTP and XML are used virtually everywhere, SOAP appears to be the most scalable remote procedure call protocol built to date, Scribner said. SOAP is not designed to act as a complete object architecture.
SOAP does not replace the Remote Method Invocation protocol in Java, Distributed Component Object Model and CORBA; it offers rules that any of these models can use. SOAP is not complete solution. It does not support object activation or protection. According to Scribner, SOAP developers "trust that users will add this code themselves" by building it on top of SOAP, rather than making it part of the protocol itself.
The figure shows an example taken from the SOAP 1.1 specification in which a host requests a quote service for the price of a particular stock. The SOAP request is embedded in an HTTP POST, and the request body specifies the type of request and the parameter - the stock symbol. The response also provides an XML object encapsulated in the HTTP response with a single return value (34.5 in in this case).
Features of SOAP
With SOAP, developers can create Web services as quickly as they write SOAP messages for program calls. existing applications, and then add these applications to simple Web pages. But in addition, developers have the ability to use SOAP calls in dedicated applications and create applications that can be ported to other people's Web pages, thereby avoiding the time-consuming and expensive development process.
According to Mark Stiver, another author of the book Understanding SOAP, this is precisely the goal Microsoft is pursuing with its promising .Net platform. “This is where SOAP shines. It gives developers a really great way to create applications without having to worry about potential incompatibilities,” he says.
SOAP example
The following example illustrates a SOAP request called GetLastTradePrice, which allows a client to send a request for the latest quotes for a particular stock.
POST/StockQuote HTTP/1.1
Host: stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction:"Some-URI"
The first five lines (part of the HTTP header) specify the message type (POST), host, payload type, and payload length, and the SOAPAction header specifies the purpose of the SOAP request. The SOAP message itself is an XML document where the SOAP envelope comes first, then XML element, which specifies the SOAP namespace and attributes, if any. A SOAP envelope can include a header (but not in this case) followed by a SOAP body. In our example, the body contains the GetLastTradePrice request and the symbol of the stock for which the latest quotes are requested. The answer to this query might look like this:
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
Again, the first three lines are part of the HTTP header; The SOAP message itself consists of an envelope that contains the response to the original request, labeled GetLastTradePriceResponse, and includes the return value, in our case 34.5.
The topic title is really a question, because... I myself don’t know what it is and for the first time I will try to work with it within the framework of this article. The only thing I can guarantee is that the code presented below will work, but my phrases will only be assumptions and guesses about how I myself understand all this. So, let's go...
Introduction
We need to start with why the concept of web services was created. By the time this concept appeared in the world, technologies already existed that allowed applications to interact at a distance, where one program could call some method in another program, which could be launched on a computer located in another city or even country. All this is abbreviated as RPC (Remote Procedure Calling). remote call procedures). Examples include CORBA technologies, and for Java - RMI (Remote Method Invoking). And everything seems to be good in them, especially in CORBA, because... You can work with it in any programming language, but something was still missing. I believe that the disadvantage of CORBA is that it works through some of its own network protocols instead of simple HTTP, which will fit through any firewall. The idea of the web service was to create an RPC that would be inserted into HTTP packets. Thus began the development of the standard. What are the basic concepts of this standard:- SOAP. Before calling a remote procedure, you need to describe this call in an XML file in SOAP format. SOAP is just one of many XML markup, which is used in web services. Everything we want to send somewhere via HTTP is first converted into an XML SOAP description, then stuffed into an HTTP packet and sent to another computer on the network via TCP/IP.
- WSDL. There is a web service, i.e. a program whose methods can be called remotely. But the standard requires that this program be accompanied by a description that says that “yes, you’re right - this is really a web service and you can call such and such methods from it.” This description is represented by another XML file, which has a different format, namely WSDL. Those. WSDL is just an XML file describing a web service and nothing more.
General approach
In web services there is always a client and a server. The server is our web service and is sometimes called the endpoint (like, end point, where they reach SOAP messages from the client). We need to do the following:- Describe the interface of our web service
- Implement this interface
- Launch our web service
- Write a client and call remotely desired method web service
Server
Let's launch IDEA and create a new project Create New Project. Let's indicate the name HelloWebService and press the button Next, then button Finish. In a folder src let's create a package ru.javarush.ws. In this package we will create the HelloWebService interface: package ru. javarush. ws; // these are annotations, i.e. a way to mark our classes and methods, // as related to web service technology import javax. jws. WebMethod; import javax. jws. WebService; import javax. jws. soap. SOAPBinding; // we say that our interface will work as a web service@WebService // we say that the web service will be used to call methods@SOAPBinding (style = SOAPBinding. Style. RPC) public interface HelloWebService ( // we say that this method can be called remotely@WebMethod public String getHelloString(String name) ; ) In this code, the WebService and WebMethod classes are so-called annotations and do nothing except mark our interface and its method as a web service. The same applies to the SOAPBinding class. The only difference is that SOAPBinding is an annotation with parameters. In this case, the style parameter is used with a value indicating that the web service will work not through document messages, but as a classic RPC, i.e. to call a method. Let's implement our interface logic and create a HelloWebServiceImpl class in our package. By the way, I note that ending a class with Impl is a convention in Java, according to which the implementation of interfaces is so designated (Impl - from the word implementation, i.e. implementation). This is not a requirement and you are free to name the class whatever you want, but good manners require it: package ru. javarush. ws; // the same annotation as when describing the interface, import javax. jws. WebService; // but here it is used with the endpointInterface parameter, // indicating full name interface class of our web service@WebService(endpointInterface= "ru.javarush.ws.HelloWebService") public class HelloWebServiceImpl implements HelloWebService ( @Override public String getHelloString (String name) ( // just return the greeting return "Hello, " + name + "!" ; ) ) Let's launch our web service as standalone server, i.e. without the participation of any Tomcat and application servers (this is a topic for a separate discussion). To do this, in the project structure in the folder src Let's create a package ru.javarush.endpoint, and in it we will create a class HelloWebServicePublisher with a method main: package ru. javarush. endpoint; // class for running a web server with web services import javax. xml. ws. Endpoint; // class of our web service import ru. javarush. ws. HelloWebServiceImpl; public class HelloWebServicePublisher ( public static void main (String... args) ( // start the web server on port 1986 // and to the address specified in the first argument, // start the web service passed in the second argument Endpoint. publish( "http://localhost:1986/wss/hello", new HelloWebServiceImpl () ) ; ) ) Now let's run this class by clicking Shift+F10. Nothing will appear in the console, but the server is running. You can verify this by typing the line http://localhost:1986/wss/hello?wsdl in your browser. The page that opens, on the one hand, proves that we have a web server (http://) running on port 1986 on our computer (localhost), and, on the other hand, shows a WSDL description of our web service. If you stop the application, the description will become unavailable, as will the web service itself, so we won’t do this, but move on to writing the client.Client
In the project folder src Let's create a package ru.javarush.client , and in it the HelloWebServiceClient class with the main method: package ru. javarush. client; // needed to get wsdl description and through him // reach the web service itself import java. net. URL; // this exception will occur when working with a URL object import java. net. MalformedURLException; // classes to parse xml with wsdl description // and reach the service tag in it import javax. xml. namespace. QName; import javax. xml. ws. Service; // interface of our web service (we need more) import ru. javarush. ws. HelloWebService; public class HelloWebServiceClient ( public static void main (String args) throws MalformedURLException ( // create a link to wsdl description URL url = new URL ( "http://localhost:1986/wss/hello?wsdl") ; // We look at the parameters of the next constructor in the very first tag of the WSDL description - definitions // look at the 1st argument in the targetNamespace attribute // look at the 2nd argument in the name attribute QName qname = new QName ("http://ws.site/" , "HelloWebServiceImplService" ) ; // Now we can reach the service tag in the wsdl description, Service service= Service. create (url, qname) ; // and then up to the port tag nested in it, so that // get a link to a web service object remote from us HelloWebService hello = service. getPort(HelloWebService.class); // Hooray! Now you can call remote method System. out. println (hello. getHelloString ( "JavaRush" ) ) ; ) ) I gave maximum comments on the code in the listing. I have nothing to add, so let’s run (Shift+F10). We should see the text in the console: Hello, JavaRush! If you didn’t see it, then you probably forgot to start the web service.Conclusion
In this topic was presented short excursion to web services. Once again, I will say that much of what I wrote is my guess as to how it works, and therefore you should not trust me too much. I would be grateful if knowledgeable people They will correct me, because then I will learn something. UPD.In general, today there are standard XML data exchange protocols:
- XML-RPC– you pass the package and indicate which method on the server you want to call.
- REST- there are some objects on the server. Each object is characterized by some kind of identifier. Each element has its own url. You can do the following with any element: insert, delete, update, select. You simply send the desired request to the server (for example, insert such and such an element). Client-server exchange is based on either JSON or XML.
SOAP (service oriented architecture, a set of loosely coupled services interacting with each other) is based on RPC. The main advantage of RPC is the small number network resources(entry points) and many methods involved. Despite this advantage, RPC is an outdated protocol that has a number of disadvantages:
- The validity of an XML-RPC message cannot be verified. The old protocol was created before schemas (methods of validating data) were standardized in XML. Those. The server accepts requests, it must ensure that the requests are for it and that the data is consistent. In XML-RPC, data types are declared for this, but this is a data type check, and data consistency is not checked (that you received a structure with all the necessary parameters).
- You cannot create combined messages.
- You cannot use space and time (appeared after the creation of RPC).
- You cannot expand the message, i.e. add additional information.
All these shortcomings were solved in XML Schema. This is the industry standard description XML document. Those. it is a way to model arbitrary data. XML schemas and can describe a model (relationships between elements and attributes, and their structure), data types (characterizes data types) and a dictionary (names of elements and attributes).
Based on all the shortcomings of XML-RPC, the SOAP protocol was created.
SOAP(Simle Object Access Protocol) - access protocol to an object (to the entry point). Today it is the main industry standard for building distributed applications.
It represents extensions to the XML-RPC language. Those. it is built on the principle: 1 entry point and any methods. The protocol itself in terms of transport (how to transfer data) gives wide selection: SMTP, FTP, HTTP, MSMQ.
SOAP underlies the implementation of XML web services (XML web services). The disadvantage of SOAP is that it is difficult to learn.
SOAP is based on the exchange of messages between a client and a server (synchronously and asynchronously). Each message carries information about the data (what data is transmitted and received). SOAP describes in advance the entire structure of a message using XML schemas: what should be in the message, how it will be transmitted. This makes it possible, without knowing the server, to understand what is happening there, and allows the server to check whether this message is for it.
XML schema
The purpose of a schema is to describe the structure of the data, i.e. what we have. All data is divided into simple and complex types (scalars and structures). A simple type (string, number, boolean, date) will never contain anything inside. And a structure (object) can contain properties.
Basic SOAP Operations
- Not just simple client-server information exchange. But also automatic server recognition and search for this server, i.e. the client may not even know anything about the server. Those. the client first searches for the server, finds suitable services, understands what methods are there, what the server has, and calls it.
- The server publishes its information (location, what methods it supports) so that the client finds this server. Publishing occurs in the UDDI directory.
SOAP message structure:
- SOAP Envelope - this includes the entire message. Consists of a header and a body.
- SOAP Header - additional information(authorization, for example).
- SOAP Body (body) - the message itself.
- SOAP Fault (error) is a method of transmitting an error from the server to the client.
WSDL
WSDL (Web Services Description Language) - language for describing web services. Used in SOAP. This is a kind of document that describes everything: what namespaces were used, what data schemes were used, what types of messages the server expects from the client, what envelopes belong to what method, what methods exist, what address to send to, etc. Actually, WSDL is a web service. It is enough for the client to study the contents of this document; he already knows everything about the server.
Any server must publish WSDL.
WSDL consists of blocks:
- Definition of the service itself, i.e. entry point, port is indicated.
- Methods format. The entry point is linked to operations, i.e. what methods does it support? The type of call and transmission method are indicated. Inside each method there is an explanation of the form in which the data is transmitted - in the form of SOAP.
- Binding methods to a message.
- Description of the messages themselves.
Lyrical part.
Imagine that you have implemented or are implementing a certain system that should be accessible from the outside. Those. there is a certain server with which you need to communicate. For example a web server.
This server can perform many actions, work with the database, perform some third-party requests to other servers, do some calculations, etc. live and possibly develop according to the scenario known to him (i.e. according to the developers’ scenario). It is not interesting for a person to communicate with such a server, because he may not be able/want to give beautiful pages with pictures and other user-friendly content. It is written and works to work and provide data when asked to it, without worrying that it is human-readable, the client will deal with it himself.
Other systems, accessing this server, can already dispose of the data received from this server at their own discretion - process, accumulate, issue to their clients, etc.
Well, one of the options for communicating with such servers is SOAP. SOAP xml message exchange protocol.
Practical part.
A web service (this is the name of what the server provides and what clients use) makes it possible to communicate with the server with clearly structured messages. The fact is that the web service does not accept any data. The web service will respond with an error to any message that does not comply with the rules. By the way, the error will also be in xml form with a clear structure (which cannot be said about the text of the message).
WSDL (Web Services Description Language). The rules by which messages are composed for the web service are also described using xml and also have a clear structure. Those. If a web service provides the ability to call a method, it must allow clients to know what parameters are used for this method. If the web service expects a string for Method1 as a parameter and the string should be named Param1, then these rules will be specified in the web service description.
Not only can parameters be passed simple types, but also objects, collections of objects. The description of an object comes down to a description of each component of the object. If an object consists of several fields, then each field is described, its type, name (what are the possible values). Fields can also be of a complex type, and so on until the description of the types ends with simple ones - string, boolean, number, date... However, some specific types may turn out to be simple, it is important that clients can understand what values they may contain.
For clients, it is enough to know the url of the web service; the wsdl will always be nearby, from which you can get an idea of the methods and their parameters that this web service provides.
What are the advantages of all these bells and whistles:
- In most systems, methods and types are described in automatic mode. Those. it is enough for the programmer on the server to say that this method can be called through a web service, and the wsdl description will be generated automatically.
Automatic validation.
- xml validation. xml must be well-formed. Invalid xml - immediately an error to the client, let him sort it out.
- schema-validation. xml must have a certain structure. xml does not match the schema - immediately an error to the client, let him sort it out.
- Data verification is carried out by the soap server so that data types and restrictions match the description.
- Authorization and authentication can be implemented using a separate method. natively. or using http authorization.
- Web services can work both via the soap protocol and via http, that is, through get requests. That is, if the parameters are simple data (without structure), then you can simply call the usual get www.site.com/users.asmx/GetUser?Name=Vasia or post. However, this is not everywhere and not always.
- ... see on Wikipedia
The description, which has a clear structure, is readable by any soap client. Those. no matter what the web service is, the client will understand what data the web service receives. Using this description, the client can build its own internal structure of object classes, the so-called. binding" and. As a result, the programmer using the web service has to write something like (pseudocode):
NewUser:=TSoapUser.Create("Vasya","Pupkin","admin"); soap.AddUser(NewUser);
There are also a lot of disadvantages:
- Unreasonably large message size. Well, here the very nature of xml is such that the format is redundant, the more tags, the more useless information. Plus soap adds its redundancy. For intranet systems, the issue of traffic is less acute than for the internet, so soap is for local networks more in demand, in particular Sharepoint has soap web service, with whom you can communicate with success (and some limitations).
- Automatically changing the description of a web service can break all clients. Well, it’s like this for any system, if it’s not supported backward compatibility with the old methods, everything will fall off...
- Not a minus, but a drawback. All method calls must be atomic. For example, when working with a database, we can start a transaction, execute several queries, then rollback or commit. There are no transactions in soap. One request, one answer, the conversation is over.
- Dealing with the description of what is on the server side (is everything described correctly?) and what is on the client (what was described to me here?) can be quite difficult. There were several times when I had to deal with the client side and convince the server programmer that his data was described incorrectly, but he couldn’t understand anything about it at all, because automatic generation and he shouldn’t, it’s a matter of software. And the error, naturally, was in the method code; the programmer simply did not see it.
- Practice shows that web service developers are terribly far from the people who use these web services. In response to any request (valid from the outside), an incomprehensible error “Error 5. Everything is bad” may come. It all depends on the conscience of the developers :)
- I'm sure I still don't remember something...
As an example, there is an open web service belavia:
- http://86.57.245.235/TimeTable/Service.asmx - entry point, there is also a text description of methods for third-party developers.
- http://86.57.245.235/TimeTable/Service.asmx?WSDL - wsdl description of methods and types of received and returned data.
- http://86.57.245.235/TimeTable/Service.asmx?op=GetAirportsList - description of a specific method with an example of the type of xml request and xml response.
You can manually create and send a request like:
POST /TimeTable/Service.asmx HTTP/1.1 Host: 86.57.245.235 Content-Type: text/xml; charset=utf-8 Content-Length: length SOAPAction: "http://webservices.belavia.by/GetAirportsList"
the answer will come:
HTTP/1.1 200 OK Date: Mon, 30 Sep 2013 00:06:44 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET X-AspNet-Version: 4.0.30319 Cache-Control: private, max -age=0 Content-Type: text/xml; charset=utf-8 Content-Length: 2940
PS Previously, the Aeroflot web service was opened, but after 1C added soap support to 8ku, a bunch of 1C beta testers successfully installed it. Now something has changed there (I don’t know the address, you can look it up if you’re interested).
ZZY Disclaimer. He spoke at the everyday level. You can kick.
