Effective C # Principle 34: Creating a large-capacity web API

The overhead and hassle of an interactive protocol is how the data media is used. There may be different uses of the media during the interaction, such as using telephone numbers, faxes, addresses, and e-mail addresses in exchange for different uses. Let's look back at the last order catalogue, and when you order by phone, you answer a series of questions from the salesperson:

"Can you fill out the first item?" ”

"The number of this item is 123-456"

"How much do you want to order?" "

"Three Pieces"

This question always asks the salesperson to fill out all the information, for example, to know your order address, credit card information, shipping address, and other necessary information to complete this transaction. It is encouraging to finish the discussion on the phone. Because you won't be a person for a long time talking to yourself, and you won't have to endure long enough for the salesperson to be quiet.

When compared to a fax order, you fill out the entire order document and send the entire document to the company. A file transfer completed one-time, you do not have to fill out the product number, fax, and then fill out the address, and then fax, fill out the credit card number, and then send a fax.

This shows a common flaw in defining a bad Web method interface. When you use a Web service, or. NET remote interaction, you must keep in mind that the most expensive overhead is the transfer of objects between two remote machines. You should not simply create a remote API by encapsulating the interface that was originally used on the local computer. Although this can work, but the efficiency is very low.

This is a bit like using the telephone to complete the task of ordering by fax. Your application waits for the network for most of the time after sending a piece of data to the channel. With the smaller API, the application is more expensive to wait for server data to return.

Instead, when we create a web-based interface, we should serialize the server and the client's series of objects, and then transmit them based on the serialized document. Your remote communication should be like the form used when ordering by fax: The client should have an extended run time period that does not communicate with the server. At this point, when the information used is completed, the user can submit the document to the server one at a time. The same thing is done on the server: When the information returned to the client arrives on the server, the customer has all the information they need to complete the order task at hand.

Metaphor says we're pasting a customer order, we're designing a customer's ordering processing system, and it's consistent with the central server and desktop users accessing information over the network. One of the classes in the system is the customer class. If you ignore the transmission problem, then the customer class may be designed like this, which allows the user to retrieve or modify the name, shipping address, and account information:

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 contain a remote-invoked API, and calling a remote user between the server and the client can 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 client object on this machine, and then send this client object to the server after the user fills out 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 );