BP REST API Messages endpoint - additional recipient data

[niftythree]

Hello,

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?

Thanks.

[espellcaste]

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 ​https://github.com/buddypress/BP-REST/blob/fbd9eab4cb37a1fd0068504e918e2af58b94e528/includes/bp-messages/classes/class-bp-rest-messages-endpoint.php#L909 and add the name of the user themselves.

[imath]

@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 ​https://github.com/buddypress/BP-REST/blob/fbd9eab4cb37a1fd0068504e918e2af58b94e528/includes/bp-messages/classes/class-bp-rest-messages-endpoint.php#L992 with an embeddable property set to true (+ the same kind of link for the sending user)

[niftythree]

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.

[espellcaste]

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.

[niftythree]

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

[espellcaste]

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: ​https://github.com/buddypress/BP-REST/pull/464

[imath]

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

[imath]

It has been fixed into the ​BP REST API