# [Proposal: posts and pages API filtering](https://github.com/kadamwhite/wordpress-rest-api/issues/121)

> state: **open** opened by: **leobalter** on: **12/30/2015**

Looking at the docs on examples like: 

```js
wp.posts().id( n ).revisions()
wp.posts().type( type_name )
```

How about fetching only a small subset of posts and pages directly on `posts` or `pages` methods as:

```js
wp.posts('id', n).revisions()
wp.posts('type', type_name);
```

On a future this can be also improved to pass a object with more includes like:

```js
wp.posts({
  id: n,
  type: type_name
});
```

This proposal should regard it might conflict with a way to set what you want from the posts, let's say you only want to fetch the comments:

```js
wp.posts({
  type: type_name,
  fetch: [ 'comments' ]
});
```

These ideas are inspired on my previous experience with Ember, and they're just suggestions which I'm sure you'll take the best decision if it's a good improvement or not for this api.

### Comments

---
> from: [**kadamwhite**](https://github.com/kadamwhite/wordpress-rest-api/issues/121#issuecomment-172935971) on: **1/19/2016**

@leobalter Thank you for the suggestion! I've been thinking about ways to implement this and the object form, such as
```js
wp.posts({
  id: 3782
}).get( // ...
```
may actually be fairly straightforward to implement. Basically, when a request object is instantiated, it will iterate through the keys of the provided object; if it has a method for that key, as there is an `.id()` chaining method to complement the `id` key, it would call that method with the value of the key in the object. I think I prefer this approach to passing in the key and variable as two separate parameters, because named arguments makes the most sense to me when there is significant specificity and creating a request object feels very general in comparison.

Thoughts?
---
> from: [**leobalter**](https://github.com/kadamwhite/wordpress-rest-api/issues/121#issuecomment-172938225) on: **1/19/2016**

the way you presented is great because it works better on the single responsibility pattern and it's less magical than jQuery-like methods we are used to (e.g.: `$.ajax`).

Your approach seems as a great approach as you're working on a web application library.