REST API chat summary – December 22, 2016

Slack log: https://wordpress.slack.com/archives/buddypress/p1482426116001568 (at the time I’m writing this, there seems to be a Slack bug that’s causing a 30-minute gap in the log)

Present: boone, codeart, chetansatasiya, chiragpatel, rekmla, ckchaudhary, espellcaste, offereins, modemlooper

I started with a couple discussion topics for moving toward our inital members endpoints:

We decided that xprofile data will be available (and updateable) via the /members/ endpoints. So the member schema will have something like an xprofile_data property, which will be an array of fields and their data. For performance, we’ll explore having a parameter that allows the client to specify the xprofile fields that should be return in a request (or to disable them altogether).
The /members/ routes will have full CRUD endpoints, even when those endpoints are totally redundant with WP’s corresponding users endpoint. This is specifically the case with DELETE.
Avatar URLs will be available as part of the default member object. We’d like to explore the ability to create and update avatars via the API, but this will be a parallel project that shouldn’t block the members endpoints. (Avatar creation will require some discovery mechanism for clients to determine the proper size/aspect ratio, and will require the client to handle crop/resize, at least in the first implementation.)

codeart and chiragpatel will spend some time over the next few weeks collaborating on a first pass at the endpoint controller and the data schema. Our next meeting will probably be during the first week of January, depending on progress; a time will be announced next week.

I’m thinking that something like WooCommerce might be adding its own user-specific info to the response from the users endpoint (maybe a paid subscription status or last purchase date, for example). The whole picture of the user might be the response from the users endpoint _and_ the BuddyPress info available at the members endpoint. As a simple example, I can imagine wanting to know whether a user has a particular BP member type and a current paid subscription via Easy Digital Downloads or WooCommerce.

If we were to add BP data to the WP users endpoint response, then querying that endpoint would return BP data and (presumably) any data added by other plugins. However, since we’ve decided to roll our own members endpoint, I’d like for it to work well for other plugin devs and people who are using the REST endpoints. Rather than requiring WC to write handlers for both endpoints, or requiring devs to query both to fetch various pieces of data, maybe we could build the response in such a way that plugins that would hook in to the user data response would also be hooked in automatically to the member data response.

When I fiddled with the BP REST API over the summer (there’s a pull request against the repo that deals with user data), I tacked the BP data on to the standard users response endpoint, so that’s the paradigm I’m more familiar with. I’m not advocating one over the other, though, because I just don’t know enough about the advantages and disadvantages of each approach.

p.s. Thanks for writing up these meeting summaries. I appreciate seeing the key questions and decisions all together, even when I’m able to attend the meeting.

dcavins 7:08 pm on December 22, 2016

I have a question about using a BP-specific endpoint to get member info. If you write a plugin that interacts with user data and may or may not be used in tandem with BuddyPress (maybe WooCommerce is a good example), are we expecting those plugins to filter user data at both the WP-default users and BP-specific members endpoint, or can we make this easier on them?
- Boone B Gorges 7:54 pm on December 22, 2016
  
  When you say “filter user data”, what kinds of uses do you have in mind? What would a WooCommerce API client be doing that would benefit from having BP information available as part of the return value?
  - dcavins 9:20 pm on December 22, 2016
    
    I’m thinking that something like WooCommerce might be adding its own user-specific info to the response from the users endpoint (maybe a paid subscription status or last purchase date, for example). The whole picture of the user might be the response from the users endpoint _and_ the BuddyPress info available at the members endpoint. As a simple example, I can imagine wanting to know whether a user has a particular BP member type and a current paid subscription via Easy Digital Downloads or WooCommerce.
    
    If we were to add BP data to the WP users endpoint response, then querying that endpoint would return BP data and (presumably) any data added by other plugins. However, since we’ve decided to roll our own members endpoint, I’d like for it to work well for other plugin devs and people who are using the REST endpoints. Rather than requiring WC to write handlers for both endpoints, or requiring devs to query both to fetch various pieces of data, maybe we could build the response in such a way that plugins that would hook in to the user data response would also be hooked in automatically to the member data response.
    
    When I fiddled with the BP REST API over the summer (there’s a pull request against the repo that deals with user data), I tacked the BP data on to the standard users response endpoint, so that’s the paradigm I’m more familiar with. I’m not advocating one over the other, though, because I just don’t know enough about the advantages and disadvantages of each approach.
    
    p.s. Thanks for writing up these meeting summaries. I appreciate seeing the key questions and decisions all together, even when I’m able to attend the meeting.
    - Ayush 1:20 am on December 23, 2016
      
      This is a nice point.We should discuss this on next meeting and will see what will be pros and cons.
    - Boone B Gorges 2:15 am on December 23, 2016
      
      It’s an interesting thought. I have a feeling that it’s going to be fairly rare for a client to actually need all of this information. Worst case, devs can “query both to fetch various pieces of data” – not really the end of the world by any means.
      
      For the record, the main arguments for introducing our own `members` endpoint vs using WP’s `users` are:
      
      Some hosts and security plugins are locking down the /users/ endpoint for security and privacy reasons
      
      Using /users/ would mean expanding the core schema in a way that might throw off clients
      
      Tying ourselves too closely to /users/ means there could be potential compatibility breaks if the WP endpoints change
      
      Keeping everything under the same namespace /bp/ makes for a more consistent and reliable dev experience
      - dcavins 3:29 pm on December 23, 2016
        
        Hi Boone-
        
        I’m not wanting to revisit the “which endpoint” decision. I’m a fan of made decisions and the decision to use a new BP-specific members endpoint is well-reasoned. I would like us to keep our eyes out for ways to make it act like more like a users endpoint replacement, which could be as simple as following the structural conventions of the WP users endpoint response and firing a particular action or filter when building the results. Happily, there’s plenty of cleverness in the group, so the results will be excellent.
        
        Happy holidays,
        
        -David
Ayush 1:20 am on December 23, 2016

This is a nice point.We should discuss this on next meeting and will see what will be pros and cons.
Stefano 4:42 am on December 27, 2016

Hi there,
I’ve been lurking the works on BP-REST for a few weeks now (what I could find on the web, at least) and just recently I started testing the v1 plugin, by downloading the master branch from GitHub.
I have a few questions but I couldn’t get what’s the right place to ask them. Could you point me in the right direction? I would avoid polluting this blog or the GitHub Issue section with noob questions…

Comments are closed.

BP Dev Updates

Follow development on the latest release

REST API chat summary – December 22, 2016