Retrieving specific Group via REST API returns an array

[ExoConsult]

Hello,

When you make a BP REST API Request to the endpoint, the result is an array. But, because we want to retrieve a specific group, there's no need to return an array of group object. Just the group object is enough.

GET {{host}}/wp-json/buddypress/v1/groups/74

Ps : In WP REST API, we don't get an array when you want to retrieve a specific Post for example.

Regards,
Didier

[espellcaste]

That's true! I actually don't have any strong feelings about it. The idea to return an array on single items was for consistency. One would expect that all endpoints returns an array, regardless if it is fetching a single item or a collection of items.

But I agree that's not how core does it but one's preference. And also that's not something set on stone, we can certainly change that to make sure single item be returned the object instead of the collection.

@imath what do you think about it?

[imath]

Hi,

Thanks for your feedback @ExoConsult

@espellcaste I believe it would be nice to only get the requested object for get_item(), update_item() and create_item() functions.

My only concern is about people already using the BP REST API as we would probably break their developments. I think we need to think about a back compatibility mechanism now it's included into core.

[boonebgorges]

This kind of change would likely require a switch to v2.

[espellcaste]

The inconvinience of getting the object from an array doesn't seem worth a version change.

[imath]

I think @boonebgorges is absolutely right. Changing now would break existing plugins for sure. About v2 I’m curious : how should we do (If we go this road) ? Include both versions into BuddyPress ? Include the latest and keep a v1 branch in the GH repo ?

[boonebgorges]

The inconvinience of getting the object from an array doesn't seem worth a version change.

I'm not saying that we need a v2 for this, only that we cannot make the change without switching to v2.

As for the broader question about v2, I don't have a good answer. I think we should make note of backward-incompatible API change requests, and when we have a sufficient number of them, we can consider introducing v2. I don't expect that we'll be ready for such a change by the time of BP 6.0.0, so this ticket probably can't be fixed for that milestone.

From a technical point of view, we would probably include both versions, and I'm guessing that the two versions would share the vast majority of their internals. I'm not sure exactly how we would organize this.

[espellcaste]

As far as I remember from our dev meeting, this ticket won't be deleted, but postponed for when a v2 of the BP REST API is created. We don't have a plan or schedule for when that might happen yet.

But improvements like that will be important to the next iteration of the API. :)

[espellcaste]

We will handle this after #9145 or as part of it.

[espellcaste]

Actually, no. First, we need to decide what features justify a V2. So I'll punt this ticket.

[espellcaste]

In 14026:

Include the V2 of the BP REST API in BuddyPress core.

We are officially deprecating the V1 of the BP REST API. And bundling the new, default, V2 of the BP REST API inside BuddyPress core. Previously, the V1 was developed as a plugin in a separate repo (​https://github.com/buddypress/BP-REST).

• One of the main differences between the V1 and V2 is how objects are returned. Single items are no longer returned as an array;
• We have a new BP_Test_REST_Controller_Testcase for testing the new API endpoints;
• We changed the names of our controllers to follow our autoloader rules;
• Removed the BP-REST plugin from wp-env and from our release script;
• And we added notices for the deprecated V1 API (endpoints and files).

Props imath & I. ;)

Fixes #8200
See #9145
Closes ​https://github.com/buddypress/buddypress/pull/337