[wp-trac] [WordPress Trac] #40748: Use REST API for Community Events

WordPress Trac noreply at wordpress.org
Mon May 22 18:43:21 UTC 2017


#40748: Use REST API for Community Events
-------------------------------------------------+-------------------------
 Reporter:  iandunn                              |       Owner:
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Future
Component:  REST API                             |  Release
 Severity:  normal                               |     Version:  trunk
 Keywords:  has-patch dev-feedback needs-unit-   |  Resolution:
  tests                                          |     Focuses:  javascript
-------------------------------------------------+-------------------------

Comment (by azaozz):

 Replying to [comment:6 rmccue]:
 > ...we don't need two controllers and their boilerplate for this
 functionality. My original thinking was to keep this quite minimal.

 Exactly, 40748.2.diff looks much much better.

 > adding this infrastructure makes it way easier to add more endpoints for
 new features in the future, since it establishes the pattern. Basically,
 the process changes from adding an item to the admin-ajax.php list and
 making a specially-named function, to adding the register call and a
 function to implement it.

 Yep, and that is a lot more valuable example than adding fully fledged
 endpoint(s) for a mostly private functionality.

 Replying to [comment:10 jnylen0]:
 > I think we should keep the schema from [attachment:40748.diff].  Even if
 this is an internal-only endpoint, one of the strengths of the REST API is
 that it provides a standardized way to describe request and response
 formats.

 Right, also having the schema would maker it a better example (following
 best practices).

 > In this case it's really helpful for developers that want to use this
 endpoint, whether that's core developers or someone writing a plugin to
 add more functionality later on.  Adding a schema also sets a good example
 for future work.

 This is a "mostly" private end point. We don't plan on maintaining 100%
 backwards compatibility and don't recommend for plugins to reuse. It may
 (and probably will) change in 4.8, 4.9, etc.

 One of the original ideas was to also add a front-end (standard) widget
 people can put on their sites. This can happen in the future and would
 mean things are likely to change a bit.

 I'm not sure what would be the best way to pass this message to plugin
 authors that may think to reuse the endpoint. Would that be in the schema
 somewhere? (Having this would also be quite helpful as a precedent for
 plugins.)

 Replying to [comment:11 flixos90]:
 > Allowing other developers to use it (if they wanna do custom things with
 community events) should be a best practice for any endpoint in my
 opinion.

 Don't think so. There are "public" and "private" use endpoints. This is a
 private use one, and I'd think most endpoints added by plugins will be
 private (even if there is a schema). Having to carry the back-compat
 responsibility is heavy enough for core, most plugins wouldn't do that.

 Like with all private functions in WordPress, plugin developers should be
 discouraged to use private (or mostly private) end points.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/40748#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list