Skip to:

#8698 closed enhancement (fixed)

BP REST API Messages endpoint - additional recipient data

Reported by: niftythree's profile niftythree Owned by: espellcaste's profile espellcaste
Milestone: 11.0.0 Priority: normal
Severity: normal Version:
Component: REST API Keywords: has-patch



When using the BP REST API "messages" endpoint, the data returned in the "recipients" section as part of the messages payload does not contain the member's name (but it does contain avatar information). This means that the party calling the API needs to then perform multiple API calls to the “members” endpoint using the respective member IDs to retrieve member information before it can be presented to the user (for example, in our case we are displaying basic member information such as their name and avatar in an Inbox/Starred/Outbox interface). Can the “name” information be added to the recipients section to bypass the need to call the members endpoint?


Attachments (1)

Recipient.png (29.3 KB) - added by niftythree 17 months ago.

Download all attachments as: .zip

Change History (11)

#1 @espellcaste
17 months ago

I'd like a second opinion from @imath.

I personally think this is a minor tweak in the code but it opens the possibility of new requests for new fields in the future.

The REST API tries to add as little content as possible, usually providing IDs so that the client can request more using the _embed field.

@niftythree Could also just hook into and add the name of the user themselves.

Last edited 17 months ago by espellcaste (previous) (diff)

#2 @espellcaste
17 months ago

  • Milestone changed from Awaiting Review to Under Consideration

#3 @imath
16 months ago

@espellcaste I like the _embed feature, if I understand well, we'd need to add a new REST API link to the recipients collection there with an embeddable property set to true (+ the same kind of link for the sending user)

#4 @niftythree
16 months ago

Hi @espellcaste and @imath,

Thanks for looking into this. We appreciate that this might open up similar requests for additional data, and that a more extensible approach would be more future-proof than just simply putting the data into the response.

Thank you.

#5 @espellcaste
16 months ago

  • Keywords needs-patch dev-reviewed added
  • Milestone changed from Under Consideration to 11.0.0
  • Owner set to espellcaste
  • Status changed from new to assigned

I'll work on adding this new embeddable property. Seems like a good approach instead of adding a new piece of user data in the response.

#6 @niftythree
13 months ago

Hi @espellcaste, hope you are well. Do you have any update on this? Thanks!

#7 @espellcaste
11 months ago

  • Keywords has-patch added; needs-patch removed

Upon further reflection, I'm not sure the _embed approach is the best one for this use case.

  • First of all, the REST API requestor won't know the IDs of the recipients before it makes the request. Meaning that an embed won't be that useful since the user won't know which recipient user ID to use (he would need to know before making the request for the recipients).
  • Second, it would be impracticable to pass embeds to all recipients in the response. This could be a few or it could be hundreds/thousands of recipients. It all depends on the community/app.

For custom recipient data, the best solution is for a dev to hook into bp_rest_messages_prepare_recipient_value and introduce their custom fields directly since we can't account for all scenarios.

The name of a recipient/user, however, seems like relevant data to be expected by default, just like we are passing the avatars even though they are not default recipient data.

See here:

Last edited 11 months ago by espellcaste (previous) (diff)

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

11 months ago

#9 @imath
11 months ago

  • Keywords dev-reviewed removed

Ok fine with me, I’ve just reviewed the PR, this will be fixed directly into the BP REST API plugin on GitHub.

#10 @imath
11 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

It has been fixed into the BP REST API

Note: See TracTickets for help on using tickets.