[ASP.NET] five tricks for developing web services

1. Disabling the http post / get protocol unless otherwise specified, .NET will try to bind the Web service to three protocols: HTTP / POST, HTTP / GET and SOAP. The reason why "trying" is because the HTTP / Get protocol may not be available because of the parameters and return types that depend on the service. The WSDL file generated by .NET will automatically contain instructions for binding these three protocols, and the client can freely choose which protocol and service communication. Just add the following in the web.config file, you can easily delete the binding of HTTP / POST and HTTP / GET protocols: Why avoid the Web service from HTTP / POST and HTTP / GET protocols? The main two reasons are safety and interoperability. HTTP / GET is not as good as SOAP, and because HTTP / GET is common in web links, the malicious people may use it to implement deception, so that others use their own security logo to call the web service, but I thought I have Click on the web link. For interoperability, SOAP is a widely used Web service communication standard, while HTTP / GET and HTTP / POST are not. Therefore, many of the HTTP / GET and HTTP / POST bindings included in .NET generated, many automatically generated proxy servers will not understand. Therefore, if your web service is not binding to the HTTP / GET and HTTP / POST protocols, it is best to cancel these two bindings. Second, use TCPTrace to view the SOAP request / answer message For those who develop web service applications, debugging may be an unusual difficult thing, because whether it is .NET SDK or VS.NET, there is no tool to view client and server Soap messages between. If .NET and non-.NET clients, the server-side interaction process has problems. To find out the root of the problem, you have the ability to view SOAP messages, because this type of problem is often related to the format of SOAP messages (for example, "Is there soapaction in the message?"). TCPTrace (www.pocketsoap.com/tcptrace) is an excellent tool for viewing such message exchange processes, which sets a tunnel between a client and server. When TCPTrace is started, it requires input target URL and port numbers, and local port numbers listening to TCPTrace. In this way, you can point STUB to this local port by setting up the URL attribute of the agent STUB (eg, localhost: 8080). TCPTrace can record all requests and answers to HTTP messages. One limitation of TcPtrace is that it determines the location where it cannot be used to view the message sent via SSL in the location of the message process. If you want to see the SOAP message sent by SSL, you can only write a custom ISAPI filter. Third, the simplified interface design is in many discussions about N-layer applications, and the design of the interface design can be said to be seen everywhere. However, for the distributed computing environment such as web services, the importance of simplifying interface design is more prominent.

When designing distributed applications, due to performance and scalability considerations, the call between the client and the server should ensure that the call between the server is as small as possible. Reducing network calls are not only beneficial to reduce communication overhead (if only one SOAP message can reach the target, do not send three messages), reduce network traffic, and improve the performance of the application. Obviously, all this is the goal of the developer dreams of. So what is the simplified interface? First, look at an example of complex interfaces: namespace ChattyService {public class ChattyService: WebService {private string username; private string password; public string Username {[WebMethod] set {username = Username;}} public string Password {[WebMethod] set { Password = password;}} [WebMethod] Public Bool Logon () {// Verify Identity Return True;}}} In this example, username and password are two properties, and the Logon () method must first set these two. Attributes. There is a problem light to see this code is not easy to note, this is UserName and Password as a web method. That is to say, each time the GET / SET operation for attributes will cause a call to the service. As required to simplify interface design, improved following code: namespace ChattyService {public class ChattyService: WebService {[WebMethod] public bool Logon (string Username, string Password) {// authenticate return true;}}} Now, username, and Password became the parameter of the logon () method. The advantage of the code after the modification is that it reduces the login operation to the server's three calls to once. On the other hand, if the number of parameters is too much, this method may look very unregistered. At this time, it may be necessary to put the parameters of the method into several complex types, for example, package username and password two parameters to a Credential object. 4. Save the application private data in Web.config to use the web service developed by ASP.NET to exert all the specials of the .aspx application, including the ability to apply private data with the web.config file (for example, the database connection string, File path, etc.). The benefits of using Web.config rather than the Global.asax file are not required after modifying the configuration. 5. Avoid using the ASP.NET session state .NET implementation session status management feature solves many of its Seniors ASP 3.0 existence, such as request serialization, but there are still some limitations.