Declare post collection params so they can be exposed - #1302

@WP-API/amigos I'm not 100% sure what we decided to do with WP_Query-style arguments (e.g. also supporting posts_per_page in addition to page).

Given we don't support WP_User_Query-style arguments et al, and trying to magically support them would be a pretty massive hack, I think we should drop them for now.

I'm not 100% sure what we decided to do with WP_Query-style arguments

I don't know if we discussed this, but it sounds like we should.

Looks like this needs some more discussion. @rmccue @joehoyle thoughts?

When we discussed this at LoopConf, I was under the impression we settled on the following:

1. Create new query params, for example page, per_page, slug etc.
2. Put all current WP_Query style WordPress query names under a filter or wp_query argument. So these would be equivalent:

GET /wp/v2/posts?per_page=10

GET /wp/v2/posts?wp_query[posts_per_page]=10

That way, we can support WordPress devs thinking the a WP_Query mindset, and give them the ability to construct more complex queries (though ofcourse of the public query vars that we currently use). Then have a clean top level args that will be consistent across all collections.

GET /wp/v2/posts?wp_query[posts_per_page]=10

I dig this — seems like a reasonable compromise.

If we're going to do it, keep the filter name so it's consistent with v1. That way, v2 = v1 + additional better named querying, rather than completely different.

I dig filter

Marking as Needs Refresh, since filter needs to be added in.

Closing in favor of #1793