Valid C # create a large-granularity web API

The cost and trouble of communication protocols are how to use data media. Different media may be used during communication, such as telephone, fax, address, and email. Let's look back at the last order. When you order by phone, you have to answer a series of questions from the SALESPERSON:

"Can you fill in the first item ?"

"This item number is 123-456"

"How much do you want to order? "

"Three"

For example, you must know your order address, credit card information, and shipping address, and other necessary information to complete this transaction. It is encouraging to finish this discussion over the phone. Because you will not be talking to yourself for a long time, and you will not endure the quietness of sales staff for a long time.

For comparison, we want to fill out the entire order document and then send the entire document to the company. One-time transmission of a file is completed. You do not need to fill in the product number, send a fax, enter the address, fax, enter the credit card number, and then send a fax.

The following describes common defects that may occur when a poorly defined web method interface is used. When using web services or. NET remote interaction, you must remember that the most expensive overhead is when objects are transmitted between two remote machines. You should not just re-encapsulate the interface used on the local computer to create a Remote API. Although this can work, the efficiency is very low.
This is a bit like a telephone call to complete the task of ordering by fax. Your applicationProgramMost of the time, after sending a piece of data to the channel, wait for the network. The more small pieces of API are used, the application waits for the server data to return a longer time than the application.

On the contrary, when creating a web-based interface, we should serialize a series of objects on the server and client, and then transmit them based on the serialized document. Your remote communication should be the same as the form used when you order by Fax: the client should have an extended running period that does not communicate with the server. At this time, when the information used has been filled in, the user can submit this document to the server at one time. The same thing is done on the server: when the information returned to the customer on the server arrives, the customer obtains all the information required to complete the ordering task on hand.

We still need to design an order processing system that is consistent with the network access information of the central server and desktop users by using the customer order example we mentioned earlier. A class in the system is the customer class. If you ignore the transmission problem, the customer class may be designed like this, which allows the user to retrieve or modify the name, shipping address, and account information:

 

 

Code
Public   Class Customer
{
Public Customer ()
{
}

// Properties to access and modify customer fields:
Public   String Name
{
//Get and Set details elided.
}

Public Address shippingaddr
{
//Get and Set details elided.
}

Public Account creditcardinfo
{
//Get and Set details elided.
}
}

 

 

This customer class does not include remotely called APIs. Calling a remote user between the server and the customer will cause serious traffic congestion:

 

 

// Create Customer on the server.
Customer C =   New Server. Customer ();
// Round trip to set the name.
C. Name = DLG. Name. text;
// Round trip to set the ADDR.
C. shippingaddr = DLG. ADDR;
// Round trip to set the CC card.
C. creditcardinfo = DLG. credit;

 

Instead, you should create a complete customer object on the local machine, and then deliver the customer object to the server after the user fills in all the information:

 

// Create Customer on the client.
Customer C =   New Customer ();
// Set local copy
C. Name = DLG. Name. text;
// Set the local ADDR.
C. shippingaddr = DLG. ADDR;
// Set the local CC card.
C. creditcardinfo = DLG. credit;
// Send the finished object to the server. (One trip)
Server. addcustomer (C );

 

This customer's example clearly and simply demonstrates this problem: the entire object is transmitted one by one between the server and the client. But to write efficientCodeYou should extend this simple example to include the correct collection of related objects. In a remote request, a single attribute of an object is a small particle ). However, for each transmission between the server and the customer, a customer instance may not be a particle of the correct size.

Let's extend this example to bring it closer to some problems encountered in actual design. Let's make some assumptions about the system. This software mainly supports an online seller with 1 million customers. Assume that each user has a main directory for house ordering. On average, there were 15 orders last year.
Each telephone operator uses one machine for shift operations and, regardless of whether the phone orderer answers the call, they need to find or create this order record. Your design task is to determine a collection of efficient objects transmitted between the client and the server.

In the beginning, you may eliminate some obvious options. For example, retrieving the information of each customer and each order should be clearly prohibited: 1 million customers and 15 million (1 million 5 million) the order record is obviously too big to go back to a customer. This makes it easy for another user to encounter bottlenecks. Each time data may be updated, it will blow up the server. You need to send a request containing 15 million objects. Of course, this is only a transaction, but it is too inefficient.

Instead, consider how you can best retrieve an object set. You can create a good data set proxy to process objects that will be used in a few minutes. An operator replies to a call and may be interested in a customer. During a telephone conversation, the operator may add or remove orders, modify orders, or modify the account information of a customer. The obvious choice is to retrieve a customer and all orders of the user. The method on the server may be as follows:

 

Public Orderdata findorders ( String Customername)
{
//Search for the customer by name.
//Find all orders by that customer.
}

 

Right? Orders sent to the customer and received by the customer may not be required on the client. A better way is to retrieve only one order for each requested user. The server method may be changed to the following:

 

Public Orderdata findopenorders ( String Customername)
{
//Search for the customer by name.
//Find all orders by that customer.
//Filter out those that have already
//Been already ed.
}

 

In this way, you still need to ask the client to create a new request for each phone order. Is there a way to optimize communication? It is better than downloading all orders included by users. We will add some new assumptions in business processing to give you some methods. Assume that the call center is distributed so that each Working Group receives different phone numbers. Now you can modify your design to optimize the interaction.

The operator in each region may retrieve and update the customer and order information at the first shift. After each call, the customer application should return the modified data to the service, and the server should respond to all modifications made after the last customer request data. The result is that after each call, the operator sends all the modifications, including all the modifications made by other operators in the group. This design means that each call has only one session, and each operator should have data set access each time he replies to the call. In this way, there may be two methods on the server:

 

Public Customerset retrievecustomerdata (
Areacode theareacode)
{
// Find all customers for a given area code.
// Foreach customer in that area code:
// Find all orders by that customer.
// Filter out those that have already
// Been already ed.
// Return the result.
}

Public Customerset updatecustomer (customerdata
Updates, datatime lastupdate, areacode theareacode)
{
// First, save any updates, marking each update
// With the current time.

// Next, get the updates:
// Find all customers for a given area code.
// Foreach customer in that area code:
// Find all orders by that customer that have been
// Updated since the last time. Add those to the result.
// Return the result.
}

 

However, this may waste some bandwidth. The last design is the most effective when every known customer calls every day. But this is probably not true. If yes, your company should have a major problem in customer service, which cannot be solved by software.

How can we further limit the transmission size without increasing the number of sessions and the server response latency? You can make assumptions about the customers preparing to make phone calls in the database. You can track some statistical tables and find that if some customers have no orders for six months, they will probably not have orders again. At this point, you should stop retrieving these customers and their orders from that day. This can contract the initial transfer size. You can also find that many customers often call to ask about the last order after placing an order through a short phone call. Therefore, you can modify the order list and transmit only the last orders instead of all orders. This may not need to modify the method signature on the server, but it will contract the size of the package transmitted to the customer.

the focus of these assumptions is to give you the idea of remote interaction: reduce the session frequency between two machines and the packet size during the session. These two goals are contradictory. You need to make a balanced choice between them. You should take two extreme vertices, instead of making the wrong choice too large or too small.