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

Add REST API endpoint #407

Open
mboynes opened this Issue Dec 3, 2015 · 6 comments

Comments

Projects
None yet
4 participants
@mboynes
Member

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 label Dec 3, 2015

@mboynes mboynes self-assigned this Dec 3, 2015

@mboynes mboynes added this to the later milestone Dec 3, 2015

@mboynes

This comment has been minimized.

Show comment
Hide comment
@mboynes

mboynes Dec 3, 2015

Member

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

Member

mboynes commented Dec 3, 2015

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

@danielbachhuber

This comment has been minimized.

Show comment
Hide comment
@danielbachhuber

danielbachhuber Dec 3, 2015

Collaborator

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

Collaborator

danielbachhuber commented Dec 3, 2015

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

This comment has been minimized.

Show comment
Hide comment
@danielbachhuber

danielbachhuber Dec 3, 2015

Collaborator

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.

Collaborator

danielbachhuber commented Dec 3, 2015

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

This comment has been minimized.

Show comment
Hide comment
@sc0ttkclark

sc0ttkclark Dec 3, 2015

Fields API ftw

sc0ttkclark commented Dec 3, 2015

Fields API ftw

@mboynes

This comment has been minimized.

Show comment
Hide comment
@mboynes

mboynes Dec 3, 2015

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@danielbachhuber

danielbachhuber Dec 3, 2015

Collaborator

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.

Collaborator

danielbachhuber commented Dec 3, 2015

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment