Skip to:
Content

BuddyPress.org

Opened 3 years ago

Last modified 2 months ago

#7156 accepted feature request

Build REST-API endpoints for all Components.

Reported by: DJPaul Owned by: espellcaste
Milestone: 6.0.0 Priority: strategic
Severity: normal Version:
Component: REST API Keywords: needs-docs needs-codex has-patch
Cc: espellcaste@…, lmoffereins@…

Description

To summarise countless discussions in the past, we need to build REST-API endpoints for BuddyPress.
Current work is happening on Github: https://github.com/buddypress/BP-REST

Technical requirements are still a bit sparse, but are currently:

  • Query parameters / filters / returned data structure should be as uniform as possible across all Component endpoints.
  • To adopt the JSON-LD specification to enrich the understandability of our endpoints by matching elements with schema.org.
  • We can ship the API incomplete with BuddyPress as we build it (once we reach certain feature completion for each Component) because we can version our endpoints very easily.


Attachments (4)

7156.patch (20.5 KB) - added by imath 6 months ago.
7156.2.patch (22.4 KB) - added by imath 5 months ago.
7156.3.patch (22.7 KB) - added by imath 4 months ago.
7156.4.patch (11.6 KB) - added by imath 3 months ago.

Download all attachments as: .zip

Change History (27)

#1 @espellcaste
3 years ago

  • Cc espellcaste@… added

@DJPaul Good!

Question, do you have usage information about the current version so far? Is there companies/sites using? #justcurious

#2 @DJPaul
3 years ago

@espellcaste Current version linked is not functional and is maybe 1/4 of the Activity endpoints.

#3 @Offereins
3 years ago

  • Cc lmoffereins@… added

#4 @boonebgorges
12 months ago

  • Milestone changed from Awaiting Contributions to 5.0.0

Moving to the 5.0.0 milestone. Checklist:

  • code review on existing endpoints (Boone is currently doing this)
  • decisions about which subset of endpoints will appear in 5.0.0
  • technical decisions about how we merge into core (leave as external project vs moving to SVN, where it lives in the filesystem, etc)

#5 @espellcaste
9 months ago

  • Keywords needs-docs needs-codex added

Just passing by to inform that all endpoints for the before-bp-merge and v1 milestones are done, reviewed and ready: https://github.com/buddypress/BP-REST/milestones

A lot of work was put into it in the past two years! So I'm very excited about that!


There are, however, some components that don't have endpoints yet. Those will be added in the next BuddyPress release.


Those are the components with endpoint support:

  • Activity
  • Group Membership
  • Group Membership Request(s)
  • Group Avatar
  • Group Invites
  • XProfile Fields
  • XProfile Groups
  • XProfile Data
  • Members
  • Members Profile Photo (aka Avatar)
  • Notifications
  • Components


technical decisions about how we merge into core (leave as external project vs moving to SVN, where it lives in the filesystem, etc)

I'd recommend keeping at GH, at least until the next version of the API is ready, just like the BP CLI and BP Default.

If everyone agrees, I can have a patch ready with an example of the implementation. :)


Another important task pending is documentation. @boonebgorges and I have been testing some options. But a page at the Codex will also be necessary with basic information and probably a link to the actual doc of the API.

#6 @espellcaste
9 months ago

  • Owner set to espellcaste
  • Status changed from new to accepted

#7 @boonebgorges
9 months ago

I'd recommend keeping at GH, at least until the next version of the API is ready, just like the BP CLI and BP Default

Sounds good to me for now.

@imath
6 months ago

#8 @imath
6 months ago

  • Keywords has-patch added

Hi,

I know we are still thinking about what is the best option between merging or including into a build step the BP REST API. Reading the thread of the ticket makes me feel, and I agree about this choice, that we can wait until all the remaining endpoints are built into the BP REST plugin before merging. It's the choice that leaves us all options: as @boonebgorges said during dev-chat "once we go Trac, we can't go back".

So I've been thinking about this scenario and built the 7156.patch. Here's what it does :

  • put the REST Controllers into their components class directory (eg: src/bp-activity/classes/class-bp-rest-activity-endpoint.php),
  • make sure all @since 0.1.0 are replaced by @since 5.0.0,
  • make sure the buddypress.pot is generated after the REST endpoints have been added to the build directory.
  • copy the functions listed into the /includes/functions.php file of the BP REST plugin into src/bp-core/bp-core-rest-api.php. (PS: I've added a pull-request about what needs to be done into the BP REST plugin about this).
  • update the class autoloader for the REST Controllers.
  • add a new method rest_api_init() to BP_Component and the components having REST controllers.
  • make sure these methods are only used when the WordPress version of the site is >= 4.7.0 and the BP REST plugin is not active.

On a side note I had to edit a unit test that was deleting the $_SERVER['SERVER_NAME'] global. Feedbacks welcome 😉

Last edited 6 months ago by imath (previous) (diff)

#9 @espellcaste
6 months ago

Really good! A few things I noticed:

  • version change: I wonder how that's gonna happen when other versions are add. Meaning, 5.0.1, etc.
  • Should the bp rest api unit tests also be migrated as well? Or only on the "final" migration/merge?
  • I think we should update the members path to the filterable one as it is in the @todo That might avoid breakages for some people
  • The svn export --force https://github.com/buddypress/BP-REST.git/trunk bp-rest is exporting from the trunk branch but there is no trunk branch on that git repo. The main one is master.

#10 @imath
6 months ago

Thanks a lot for your feedbacks @espellcaste

About version change, I think we just need to increase the version number of the BP REST plugin once BuddyPress 5.0.0 is released for instance:

  • 0.1.0 => 5.0.0
  • 0.1.1 => 5.1.0
  • 0.2.0 => 6.0.0

About unit tests, I'd say final merge because you need them to carry on developing the remaining endpoints from GitHub in this scenario. (it helps doing a first "review" of PRs)

About the @todo: I think it can be removed because the function is already using the filterable path. I've read the history of the file and, the @todo appeared in 40b1288 but wasn't removed in a305cf7

About svn export, SVN trunk == GIT master 😉. It's the way to do it.

This ticket was mentioned in Slack in #buddypress by imath. View the logs.


6 months ago

@imath
5 months ago

#12 @imath
5 months ago

FYI 7156.2.patch is updating the patch to take in account the latest changes made here about the /includes/functions.php file of the BP REST plugin.

#13 @espellcaste
5 months ago

  • Milestone changed from 5.0.0 to Up Next

#14 @espellcaste
5 months ago

  • Milestone changed from Up Next to 5.0.0

Ops! My mistake!

This ticket was mentioned in Slack in #buddypress by imath. View the logs.


4 months ago

#16 @espellcaste
4 months ago

Patch looks ok to me! Nice work! :)

This ticket was mentioned in Slack in #buddypress by imath. View the logs.


4 months ago

@imath
4 months ago

#18 @imath
4 months ago

7156.3.patch is an updated version of .2 patch.

#19 @imath
4 months ago

In 12451:

Prepare BuddyPress to welcome the BP REST API

  • Add a grunt tasks to import the master branch of the BP REST API into the BuddyPress /build directory.
  • Add some other grunt tasks to move each BP REST Controller class into their corresponding component classes directory.
  • Add the needed mechanism to make sure activating the BP REST API plugin will take over the BP REST API in BuddyPress core so that it is possible to iterate/fix bugs from the BP REST API GitHub repository.
  • Make sure the buddypress.pot is generated once the BP REST API has been imported.
  • Update the BuddyPress class autoloader to manage the loading of the BP REST API Controllers.
  • Add a new method rest_api_init() to the BP Component API to register the BP REST Controllers from their belonging component classes.

Props boonebgorges & espellcaste

See #7156

@imath
3 months ago

#20 @imath
3 months ago

Hi!

In 7156.4.patch I'm suggesting to introduce a filter to allow site owners to eventually disable a specific BP REST Controller to load.

#21 @imath
3 months ago

In 12463:

Improve the way BP REST API Controllers are loaded

Introduce a new filter to allow site owners to eventually disable one or more BP REST API Controllers.

See #7156

#22 @imath
2 months ago

  • Milestone changed from 5.0.0 to Up Next

Moving this ticket to up/next milestone so we can use this ticket to carry on working on the remaining endpoints.

#23 @imath
2 months ago

  • Milestone changed from Up Next to 6.0.0

Move the first tickets to next major release.

Note: See TracTickets for help on using tickets.