Skip to content
This repository has been archived by the owner on Sep 24, 2018. It is now read-only.

There's any way to filter the GET /posts request? #2509

Closed
joanlopez opened this issue May 23, 2016 · 1 comment
Closed

There's any way to filter the GET /posts request? #2509

joanlopez opened this issue May 23, 2016 · 1 comment
Labels

Comments

@joanlopez
Copy link

Hi mates,

I'm building a personal Wordpress. It will be accessible from a typical url: blog.example.org.

In my case, i'm using the WP-API because I wanna show a random post from my blog on another site: example.org.

So, my question is:

There is any way to get only the ids of the available (published) posts?

Of course, I could retrieve all the posts with a simply GET /posts call, but this option implies a lot of unnecessary data because it returns all the data from all the posts while I only need one post, and apart from the performance, it could be critical for mobile devices without a wifi connection.

Also another nasty solution is to have a hardcoded array on my frontend, pick one randomly and make the GET /posts/id request only for the chosen one. I'm not sure which option is worst, because this implies that I have to update my frontend on each post publication..

If there's not implemented solution yet. Are you open to my contribution for this task? Or I should make my own plugin?

Many thanks!

@joanlopez joanlopez changed the title There's any way to filter GET /posts There's any way to filter the GET /posts request? May 23, 2016
@danielbachhuber
Copy link
Member

There is any way to get only the ids of the available (published) posts?

There isn't, no.

At some point in the future, we may include a flag to include or exclude specific fields: #572

If there's not implemented solution yet. Are you open to my contribution for this task? Or I should make my own plugin?

You'd be best writing your own plugin for this, at this point.

kadamwhite added a commit that referenced this issue Oct 7, 2016
This PR builds upon discussion in #2771, #572, #2350, #2509, #1530,
 #1371, #446, #827, and the trac ticket [38131][trac], proposing an
solution implemented within this plugin's wp-rest-controller class.

The patch implements a `?fields=` filter parameter that takes a comma-
separated list of field names, e.g. "id" and "title". It mirrors the
fields parameter implemented within the [WordPress.com API][wpcom]:

Parameter | Type | Description
--- | --- | ---
fields | (string) | Optional. Returns specified fields only. Comma-separated list. Example: fields=ID,title

This interface was previously implemented in [this plugin][origplugin],
and could still be implemented trivially as a plugin; however, referencing
the [2016 Ericsson Mobility Report][mobility-report] and the democratic
focus of WordPress, transferring as little data as is necessary for a
given interface is a responsibility I submit that we should take on as
application developers, and that _should_ therefore be a first-party
capability of the API, as it is for .com's.

Introducing this field has no risk of breaking the contract between
the API and clients you do not control, as the `fields` list would
only alter the response when provided so each client can tailor its
own responses to the subset of data relevant to that interface.

Open questions:

- Is there a less repetitive way this could be implemented across
  controllers, or is this duplication within each controller necessary?
- How would I register `fields` as a globally-applicable parameter
  for exposure in the schema, whitelisting, etc?
- How sould/How should we restrict this to GET requests only?
- What degree of per-controller testing is needed?

[mobility-report]: https://www.ericsson.com/res/docs/2016/mobility-report/ericsson-mobility-report-feb-2016-interim.pdf
[trac]: https://core.trac.wordpress.org/ticket/38131
[wpcom]: https://developer.wordpress.com/docs/api/1.1/get/sites/%24site/posts/
[origplugin]: https://wordpress.org/plugins/wp-rest-api-filter-fields/
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants