Custom post type and metadata support in the REST API
An internal tool that I’m building at Automattic is using the WordPress.com REST API. As part of that tool, I needed access to custom post types and post metadata, so I’ve added both to our REST API. And now anyone on a Jetpack-powered site can also use this part of the REST API. Find out the details in this developer blog post.
We’ve recently made some updates to the REST API which is available here on WordPress.com and for any Jetpack-enabled site that has the REST API module activated. The API now has full read and write support for custom post types and post metadata.
You can specify a post’s post type when you create or edit it. If you’re fetching a single post, you will receive its post type in the response. Of course, you can also specify a post type when fetching a series of posts. In all cases the parameter to use or look out for is type
.
You can also query posts by metadata
using the new meta_key
and meta_value
parameters. You can add, update, delete or retrieve a post’s metadata when creating, editing or getting a single post, using the new metadata
parameter which accepts an array of metadata key
s, id
s, previous_value
View original post 324 more words
I’ve voiced my request before w/ Beau, but it would be super helpful if plugins could hook into the Jetpack REST API too. The solution we came up with was to add a single generalized API endpoint, which plugins could then hook into. It would work sort of like how admin-ajax.php works, you pass it an action or identifier, and the WP site on the other side runs whatever it needs to on the other side. It would allow Pods sites to communicate w/ each other (via Jetpack) and other plugins to do the same. Help make this happen and I’ll…. I’ll…….. I’ll release more open source awesomeness into the wild 😉
Put in another good word for me, won’t you 🙂
I’ve seen that idea float around internally. Nothing concrete as far as I know; and I think there are some general security concerns around this, though it’s a good idea.
Hopefully allowing plugins to hook into (as described in this post) the API to allow their CPTs and metadata to work, is already a good step in the right direction 🙂
I’m open to any solution that allows plugins to communicate through the Jetpack REST/JSON API. This is definitely a good step closer, but I’ll give it a spin.
You can see the trail I was going down as documented here in this new Pods component ticket:
https://github.com/pods-framework/pods/issues/953