MVC, pagination, and massive search criteria

Question

I am currently working on a project that has a fairly large search form - the form is 30 or fields or more.

Now I can of course map this out for routing by having my application pull the parameters and handle it as usual - but as you can imagine having that many fields can grow the URL to the near max character limit and becomes difficult to manage.

My question is this I suppose - what mechanism do people generally deploy for this? Should I store search criteria in the session and have it expire? That is the only way I can see getting around forcing the pagination to "post" variables (via javascript etc. to continue the search criteria).

I'm looking to keep this as manageable as possible. This search criteria is in a private application so I do have room for flexibility.

This is being built in PHP, JavaScript, CSS and isn't using any specific flavor of framework - although it is using the traditional MVC design pattern.

Any thoughts, help, past experiences handling this is appreciated.

Answer 1

Practical URL length limit is around 2000 characters - think about whether you could optimize you filters to fit into it.

It this is not possible I'd probably implement this as a POST request. Disadvantages:

• although this is in line with HTTP semantics of POST request (POST can be used for almost anything), it's not a best fit - it's effectively nullipotent request which could be cached by proxies, but now it can't be cached because it is POST. In practice I don't think this is very important, especially if it's some kind of internal application.
• you can't copy & paste the URL from the browser to e.g. send the filter settings to a colleague
• there's a bit weird behavior when you want to refresh the page - refreshing POST request causes the browser to ask you whether you want to re-submit the POST request. Workaround for this is that result page itself is GET which loads the data from the backend using AJAX POST.

Using session introduces state into the interactions which kind of violates one of the basic principles of HTTP. If you use GET to fetch the data, results can be cached, but this can actually produce wrong results because it depends on a state stored in backend. You should make sure that your GET pages with dependence on state can't be cached. Doing stateful interactions is also more complex in general, you need to always think in what state you are now and into what state you want to go which isn't always easy.

I actually implemented filtering using session few years ago, but for a different reason - filter settings will not be erased if you go to different pages and then come back. This is useful for a lot of applications.

But if you don't need this filter settings "persistence", I'd recommend you to use POST, as it is just simpler to use (correctly).