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.