RESTfulGET: Is it necessary to modify a large number of parameters?

For example, design a GET interface to obtain the GETshop1goods product that meets the conditions? Parameters may be varied, such as name, create_time, description, status, owner... in this case, if you do not consider RESTful, It will be designed as POST. But now the RESTful style requires GET. How can this problem be solved? For example, you can design a GET interface to obtain products that meet the conditions.
GET shop/1/goods?
Parameters may be varied, such as name, create_time, description, status, owner...

In this case, if you do not consider RESTful, It is designed as POST.

But now the RESTful style requires GET. How can this problem be solved? Reply content: Conclusion: Yes. Using POST to process search requests with long parameters does not violate REST.

Let's talk about what can be improved in the answer provided by @ Zhang Lili. In Zhang's theoretical gameplay:

There is a URL like this:

/Goods/product set

Flexibility is not necessary. If a component is not supported because the URI may be too long, you can change the component.

According to Fielding Dissertation: CHAPTER 6: Experience and Evaluation 6.3.2.5 Size Limits:

There is no limit in the HTTP protocol on the length of URI

Although

Although older Web clients have a well-known problem with URI that consist of more than 255 characters

Solution:

Applications within a controlled context (such as an intranet) can avoid those limits by replacing the older components

First of all, it is possible to admit that the total length of the get url exists. A typical scenario is to select multiple IDs.

Of course, a reasonable application should not make this happen. After all, it should be hard to pick out a link that can exceed the URL length limit. Our dear product group should be considerate for users.
For scenarios such as "select all" and "cancel a few after select all", I doubt whether the latter's user scenario actually exists. Second, I can use the all-selected and inverse-selected tags for implementation, it's not a problem.

What should I do if I continue to say that the URL length limit is exceeded? The first reaction is to use POST, but to use POST to remove the semantics and REST specifications of the tutorial, a very serious impact is: Unable to use HTTP Cache
Of course, this is not a big problem. After all 99.99% of applications do not carefully design HTTP caches.(Yes, this sentence is being sprayed by many engineers, including themselves). Therefore, in this search scenario, there is almost no HTTP cache support from the very beginning.

What should I do if I still want to cache or follow the REST rules to use GET? Here is a theoretical method.
Suppose we search for a product with a URL like this:

/Goods/product set

Get can also bring the body to the main user's question. It is a typical question. I am often asked by someone. All of my answers are: Don't worry, you can't do RESTful at all.

Most people understand that RESTful is an interface design form, and sometimes it is found that some requirements cannot be made into a RESTful form at all, but in my opinion, RESTful is a problem that should be considered from the underlying architecture, or an architectural design idea, not just for interfaces.

For example, if you want to let me do this, I will design two interfaces.
POST/shop/1/query create a query for a product and return the id
GET/shop/1/query/{id} GET the result of a query

Why is it designed like this?
1. In RESTful, URI indicates resources. html/image files are resources, and query services are resources.
2. In RESTful, POST is used to create or update resources, and GET is used to obtain resources.

However, obviously, this certainly does not meet the requirements of the subject, and the existing architecture cannot meet such requirements. Therefore, I advise the subject not to worry about the RESTful architecture, how can we do this? --- Update 20160213 ---

Suddenly, it seems that the Polyfill solution is similar to the idea of @ Liqing kids shoes ..

--- Update 20160213 ---

As @ Zhang Lili @ Liu shangqi said, it is true that the query condition is too long, but tends to think that the API design is too complicated (for each Entity interface, you must design another Query. And causes the inconsistency between conditional query and unconditional Query Interfaces, and uses an intermediate type with no exact Representation. Therefore, a concise and consistent universal interface is provided here.

1. Unconditional query:


GET directly.

GET /goods HTTP/1.1

GET/xxx? Type = [1 | 2 | 3 | 4 | 5 | 6 | 7 | 8] The test is not satisfactory,! Don't hit me! The front-end uses happy response strings either get with query string or post with body. Get with body does not comply with http specifications, so there are future problems.

Trade-offs:

• The length of query string varies with the client browser (Firefox, Chrome, IE) and server (Apache, IIS. In addition to common key-value pairs, query string can also contain set parameters, which may exceed the length limit. Be careful
• Get + query string is more cache-friendly
• Get + query string can be added to the favorites folder of a browser
  
• Get + query string is more friendly to search engines

For complex search into post, it does not necessarily violate Restful. You can understand that each search result is a newly created temporary set. Restful was originally installed. It is not necessary to be so real first, RESTIs a design style rather than a standard, if an architecture meets RESTPrinciple, we call it RESTfulArchitecture.

The key lies in how to abstract resources. The better the abstraction, the more compatible the interface design. RESTStyle, that is, you can enjoy more "benefits" brought by HTTP. You need to know that Roy Fielding is back to college after completing the HTTP 1.1 design. In his doctoral thesis, he summarized REST.

However, just like all the contradictions in the procedural world, abstract problems in reality cannot be perfectly mapped.

================================ Enter the subject ============================ ====

Whether a search can be abstracted into a resource depends on how you view and use this interface. Generally, a resource has several CURD interfaces. RESTConcept ,The resource "Search" can be understood as follows:

Split into create (POST) and read (GET) interfaces. create transmits the keyword to the server through the POST method to create a resource, and then displays the final search result through the GET method.

At the same time, another benefit is to record the user's Search history. A user resource is linked to multiple Search resources, and each resource only has its own GET method, however, we didn't provide Mappings of other methods on the server.