Skip to content

Add REST API endpoint #407

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
3 tasks
mboynes opened this issue Dec 3, 2015 · 7 comments
Open
3 tasks

Add REST API endpoint #407

mboynes opened this issue Dec 3, 2015 · 7 comments
Labels
enhancement New feature or request
Milestone

Comments

@mboynes
Copy link
Contributor

mboynes commented Dec 3, 2015

Fieldmanager should add a custom REST API endpoint that allows an application to query field information for a context/subcontext. This would allow apps like Calypso, mobile apps, etc., to leverage field data to render an editing interface for Fieldmanager fields.

At a high level, we'd need to:

  • Add a GET endpoint to surface base field data (field type, label, description, etc.) for all fields added to a given context and subcontext (e.g. term/category or post/post)
  • Sanitize and save data on create and update requests for posts, user, and terms
  • Add endpoints for submenu contexts
@mboynes mboynes added the enhancement New feature or request label Dec 3, 2015
@mboynes mboynes self-assigned this Dec 3, 2015
@mboynes mboynes added this to the later milestone Dec 3, 2015
@mboynes
Copy link
Contributor Author

mboynes commented Dec 3, 2015

@danielbachhuber would be very interested in your two cents on this

@danielbachhuber
Copy link
Contributor

Lots of thoughts on this :) I'll do my best to distill them into a comment.

First off, I wholly agree with the goal: it should be possible for a REST API client (let it be Calypso, a mobile app, or my watch) to easily consume and produce custom, arbitrary WordPress data. By "custom", I mean any resource or attribute not included in the REST API included in a stock install of WordPress. By "arbitrary", I mean the resources and attributes can vary from WordPress install to WordPress install, and the client should adapt accordingly.

However, I disagree with the proposed implementation as it's a bit antithetical to the idea of REST. One key idea in REST is the concept of Resources — entities represented through the API in their purest form. If my data model includes a brand attribute for Posts, then I should be able to update it with:

POST /wp-json/wp/v2/posts/<id> brand==foo

Similarly, if I GET /wp-json/wp/v2/posts/<id>, then my response should contain:

{ 'id': <id>, 'title': 'My Awesome Post', 'brand': 'foo' }

I shouldn't need a separate, bespoke endpoint for getting or updating post meta. This intent was originally captured in #404


Which brings us to the question: how can a client know which extra fields are present on a resource, and how it should represent them within the client?

The short answer is: we don't yet know. Some people (including me) think we need a standardized mechanism for auto-discovery of custom fields; others think it's an unsolvable problem and responsibility falls upon the client.

For a fun bedtime read, check out this thread: WP-API/WP-API#759

Currently, we have very limited support for auto-discovery. Endpoints can register a schema, and the schema is exposed (along with endpoint arguments) when you make an OPTIONS request: https://gist.github.com/danielbachhuber/20483fa948cec8d9c7b4

@danielbachhuber
Copy link
Contributor

In order for Calypso and other clients to consume / produce arbitrary resources and attributes, the work to be done is to formalize the auto-discovery format, and ensure it's actually sufficient for clients to use.

@sc0ttkclark
Copy link

Fields API ftw

@mboynes
Copy link
Contributor Author

mboynes commented Dec 3, 2015

I shouldn't need a separate, bespoke endpoint for getting or updating post meta. This intent was originally captured in #404

I may have made it confusing, but I wasn't suggesting a new endpoint to get or update post, term, or user meta. We would leverage the existing infrastructure for that, but we do need to hook into the save process to properly sanitize the data. We would also -- as far as I know, but do correct me if I'm wrong -- need to add endpoints to surface data for any submenu context.

@danielbachhuber
Copy link
Contributor

We would also -- as far as I know, but do correct me if I'm wrong -- need to add endpoints to surface data for any submenu context.

Right — but the fields you'd normally edit through a submenu should be exposed through their corresponding Resource, not in an endpoint generated by Fieldmanager.

@yaronmirowebpals
Copy link

Hi,
any news regarding this feature, is it something that is planned on the road map for the near releases ?
It would be awesome if we have a full support of REST API out of the box.

Example Routes:

  • GET /wp-json/wp/v2/posts/<id> => returns post data including the post meta defined by fieldmanager.

  • GET /wp-json/wp/v2/fieldmanager/<post-type> => returns the associated fieldmanager data to that given post type.

One more thing that is also super important (at least that's how I see it) is to have endpoints that exposes Fields,
Contexts and Datasources as well, this way we can get the whole picture.

Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants