Original address: http://rest.elkstein.org/
Learn rest: a tutorial
Some ideas for designing the rest architecture are as follows:
- Do not use the "physical" URL. The physical URL points to a physical location, for example, an XML file: "http://www.acme.com/inventory/product003.xml.pdf ".LogicThe URL does not imply the physical location of the file "http://www.acme.com/inventory/product/003 ".
- Of course, content can be dynamically generated despite the XML extension. However, for us, the URL should be logical, not physical.
- Too much data cannot be returned during query. If you need to return a large amount of data, a paging mechanism is provided. For example, the "product list" GET request should be returned beforeNProducts (for example, the first 10 products) can be viewed through links on the previous or later pages.
- Although rest can respond to anything, it is necessary to ensure that the response content is described in detail in a document without changing the output format (even if it is a small change, this may cause the client to crash)
- Technology, even if the output is read-only, your client is not a person
- If the output is XML, make sure that your document is composed of the corresponding schema or DTD.
- Instead of letting the client build RSL on its own, for example, the product list request returns the ID of each product and then through the http://www.acme.com/product/Product_idTo access the product details. This is not a good design. Instead, the actual URL of each item should be included in the response, such as the http://www.acme.com/product/001263
- Yes, this means there will be a lot of output content, but it also means it is easier to direct the client to the URL they need without changing the clientCode.
- The status cannot be changed when a request is made through get. Only the POST request (or other HTTP verb, such as delete) can change the server status.
