Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
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:
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
Similarly, if I
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
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.
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.
One more thing that is also super important (at least that's how I see it) is to have endpoints that exposes