-
Notifications
You must be signed in to change notification settings - Fork 99
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
Comments
@danielbachhuber would be very interested in your two cents on this |
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 |
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. |
Fields API ftw |
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. |
Hi, Example Routes:
One more thing that is also super important (at least that's how I see it) is to have endpoints that exposes Thanks. |
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:
The text was updated successfully, but these errors were encountered: