Add REST API endpoint

[mboynes]

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]

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

[danielbachhuber]

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]

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]

Fields API ftw

[mboynes]

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]

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]

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.