Powerful Tool for front-end and back-end separation: a practical example of Fiddler

tag: blog HTTP Io OS uses AR file data 2014

# Powerful Tool for frontend and backend separation: Example of Fiddler's practical functions # What's fiddlerfiddler is a proxy software that is very important for frontend and backend separation development. It can be said that if front-end development does not use fiddler or similar software, it cannot be regarded as a real front-end development. Fiddler has three practical functions: proxy, response (reverse proxy), and request creation. For download and installation, use search engine. After installation, set the corresponding software proxy to Fiddler. The default proxy is http: // 127.0.0.1: 8888 /. You can modify the port in Fiddler options .! [Fiddler options] (http://images.cnitblog.com/blog/84053/201409/132352189349400.jpg ). # Principle 'agent' is the source of all fiddler functions .! [Fiddler proxy illustration] (http://images.cnitblog.com/blog/84053/201409/132339020434823.jpg), Fiddler sets up a proxy before the client and the server, all requests are forwarded by Fiddler, and all the responses are also. Therefore, after obtaining the data, Fiddler can provide a series of functions: ** capture and monitor all HTTP requests on the local machine, display or modify their content **. (The capture switch is available in the lower left corner.) It also provides detailed viewing of JSON, XML, images, binary, or authentication, cookies, and time analysis, people who are familiar with HTTP know the request components. Response functions are also available. In short, data transmitted over HTTP is recorded, analyzed, and even transformed. # In the era when mobile devices are used as proxies, it is not easy to debug the HTTP requests on them. Small screens are generally provided to users, leaving few development locations, in this case, you can use Fiddler to monitor it. To enable a mobile device to use the fiddler proxy (that is, the channel shown in figure 2, instead of directly accessing the server), you must enable the corresponding option in Fiddler ,! [Fiddler remote connection SWITCH] (http://images.cnitblog.com/blog/84053/201409/132352189349400.jpg) write down the port, hook ** allow remote computers to connect **, and then in the WiFi of the mobile device, find its advanced settings (usually by holding down the specific WiFi connection), set the proxy, and fill in the IP address and port. All requests and responses on the mobile device are displayed in the main window of Fiddler. # Build a response after fiddler receives a response from the server, if it returns the response as it is, it is too monotonous. Its very practical function is to process the response, change to what you want. In development, we usually need to change the response to a local file (before the background interface is complete )! [General response method] (http://images.cnitblog.com/blog/84053/201409/140018287935834.jpg), drag and drop a piece in the monitored HTTP Request/response to the 'autoresponder' page, you can "manually ", you can use a regular expression to match multiple requests and change 'extract' to 'regex. You can find out the specific operation. This function is of great significance * frontend development can be parallel with backend interface development. You only need to create some experimental data locally and direct the Request Response to the data file, you can perform most code development. * Sometimes there are bugs in online applications and we cannot submit frequent changes to them. You can use this function for local debugging (direct online code to a local machine) and click OK to go online. # Reverse proxy is also available on the 'autoresponder' page. Generally, requests are forwarded. The application scenario is as follows: I have a development environment: http: // A/WSDL/, and a test environment: http: // B/WSDL/. The two environments are obviously different in data, sometimes, if you want to test the code in another environment, can you run it correctly? How can this problem be solved? Is it a great deal of effort to deploy it on B ?, Actually no, you only need to add a rule | if request matches... | then repond... | -- | RegEx: http: // A/WSDL/| http: // B/WSDL/| note that the '/' At the end of the URL cannot be omitted, this is the basis of HTTP. Therefore, requests directed to a are automatically converted to requests directed to B and do not cause cross-origin requests. This is very useful for front-end debugging interfaces (** fixed URLs and not necessarily set parameters **). the development, testing, and production environments can be switched at any time. In practice, it is very easy to use. # The request debugging interface sometimes needs to directly send data. At this time, we can create a request. Similar to response creation, you can switch to the 'composer' page and drag and drop a request to modify its content. After modification, you can send the 'execute 'command back. You can immediately create the desired data format to send requests to the interface. # Other functions * for parameter formats, we can also use its own 'textwizard 'to convert the format, base64, URL encoding (% form), HTML encoding (starting ), JS Unicode (starting with \ U) and so on, you can explore it on your own. * You can customize the fiddler rules by script. First, install the syntaxview plug-in. For more information, see http://kb.cnblogs.com/page/130#/javasscript. # In the final analysis, as a proxy, Fiddler can display and analyze HTTP data, modify HTTP data, and provide related auxiliary functions.

powerful tool for front-end and back-end separation: a practical example of Fiddler