RESTful GET, if there are a lot of parameters, is it necessary to work around?

For example, a get interface is designed to get the product that satisfies the condition.
GET shop/1/goods?
Parameters may be multifarious, 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 a get, how to handle it would be more appropriate?

Reply content:

First of all, you can use post to handle long search requests without violating rest.

Also say @ Zhanglili classmate's answer can improve the place. In the theory of Zhang's play:

There is such a URL:

/goods/ 商品集合

Modifications are not necessary. If it is because the URI may be too long, causing a component to not be supported, then a different component is fine.

According to Fielding Dissertation:chapter 6:experience and Evaluation 6.3.2.5 Size Limits mentioned:

there is no limit in the HTTP protocol

on the length of URI

Although

Although older WEB clients has a well-known problem with URI that consist

of more than 255 characters

The workaround is to:

applications within a controlled context (such as an intranet) can avoid those limits by replacing the older Compone NTS

The first thing to admit is that the total length of URLs over get can actually exist, a more typical scenario is a multiple-choice ID, and the ghost knows how many a pervert can pick.

Of course a reasonable application should not let this happen, after all, by hand check to be able to exceed the URL length limit should be cramps, our dear product group should be for the sake of the user
As for the scenario of "Select All" and "cancel a few after selecting all", I doubt whether the latter's user scenario really exists, and the other can use the Select and reverse tags to give the implementation, and it's not a hassle.

Go on, really. Beyond the URL length limit what to do, the first reaction is naturally to play with the post, but using post to remove the dogmatic semantics and rest specifications, a very serious impact is Unable to use HTTP cache
Of course this is not a big problem, after all 99.99% of applications are not designed with an elaborate HTTP cache(yes, this is a lot of engineers that are involved in spraying themselves), so searching for this scenario is almost without HTTP cache support from the start

What if I still want to cache, or do I want to follow the rest specification using get? There's a theoretical play here.
Let's say we retrieve a product and have a URL like this:

/goods/ 商品集合

Get can also take body landlord's problem is a very typical problem, often someone asked me. My answer is: Don't toss, you can't do restful.

Most people understand that restful is a form of interface design, and then find that there are times when some needs are simply not a restful form, but it seems to me that restful is a problem that should be considered from the underlying architecture, or an architectural design idea, not just the interface.

For example, if you want me to do this, I'll design two interfaces.
Post/shop/1/query new query for a product, return ID
Get/shop/1/query/{id} Gets the results of a query

Why are you designing this?
1.RESTful, URIs represent resources, html/pictures Such files are resources, and query services are also resources
2.RESTful, post is used to create or update, get to get resources

But obviously, this certainly does not meet the needs of the main problem, to do so the existing structure must not meet, so I advise the Lord don't toss what restful, how good to do how to---update 20160213---

Suddenly found that seemingly polyfill's plan seems to be similar to the idea of the Blue children's shoes.

---update 20160213---

As @ Zhang Li @ Liu Shangxi says, it is possible that the query condition is too long, but tends to think that its design API is too complex (for each Entity interface, design a different query interface), and results in an inconsistency between the conditional query and the unconditional query interface, and the use of an intermediate type with no exact representation. So here is a simple and consistent universal interface.

1. Unconditional inquiry:


Direct GET.

GET /goods HTTP/1.1

Get/xxx?type=[1|2|3|4|5|6|7|8] Try not to, but! Don't hit me! The front end is also pretty happy ... either get with query string or post with body. The Get band body does not conform to the HTTP specification, so there is a sequel.

Weighing factors:

• The length limit of the query string varies depending on the client browser (Firefox, Chrome, IE) and the server (Apache, IIS). Query string, in addition to the normal key-value pairs, can also contain set parameters, which are likely to exceed the length limit, be careful
• Get+query string is more friendly to the cache
• Get+query string can be added to browser favorites
  
• Get+query string is more friendly to search engines

A post for complex search does not necessarily violate the restful. As you can understand, the result of each search is a newly created temporary collection. It's a restful thing to pretend to be, no need to be so serious first, RESTis a design style rather than a standard, if an architecture conforms to RESTPrinciple, we call it RESTfulArchitecture.

The key is how to abstract resources, the better the abstraction, interface design is more consistent with RESTStyle, the "benefits" of being able to enjoy more HTTP, knowing that Roy Fielding was completing the HTTP 1.1 design before returning to university to read a blog, summarizing in his doctoral dissertation REST。

However, as in all procedural worlds, abstract problems in reality can never be perfectly mapped.

===================== into the Chase =====================

Search can be abstracted into a resource, depending on how you view and use this interface. In general, a resource will have curd of several interfaces, if hard to apply RESTThe concept ,The resource that corresponds to "search" can actually understand this:

Split into the Create (post) and read (GET) interface, create through the POST method to pass the keyword to the server creates a resource, and then through the GET method to display the final search results.

At the same time there is a good thing is to record the user's search history, a user resource chain followed by multiple search resources, each resource has its own GET method, but we do not provide other methods on the server mapping.

