Skip to:

Opened 3 years ago

Last modified 4 months ago

#8200 assigned enhancement

Retrieving specific Group via REST API returns an array

Reported by: exoconsult's profile ExoConsult Owned by:
Milestone: Under Consideration Priority: normal
Severity: normal Version: 5.0.0
Component: REST API Keywords: dev-feedback



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.


Change History (10)

#1 @espellcaste
3 years ago

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?

#2 @imath
3 years ago

  • Keywords dev-feedback added
  • Milestone changed from Awaiting Review to 6.0.0


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.

#3 @boonebgorges
3 years ago

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

#4 follow-up: @espellcaste
3 years ago

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

#5 @imath
3 years ago

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 ?

#6 in reply to: ↑ 4 @boonebgorges
3 years ago

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.

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

3 years ago

#8 @espellcaste
3 years ago

  • Milestone changed from 6.0.0 to Up Next
  • Owner set to espellcaste
  • Status changed from new to assigned
  • Type changed from defect (bug) to enhancement

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. :)

#9 @imath
5 months ago

  • Milestone changed from Up Next to 12.0.0

#10 @espellcaste
4 months ago

  • Milestone changed from 12.0.0 to Under Consideration
  • Owner espellcaste deleted
Note: See TracTickets for help on using tickets.