Datamodel is wrong in API documentation

Ask the Community Password Manager
1

Hi there,

I noticed this day that there is an important difference between data returned by /public/collections/{id} and /public/collections.

The API doc states that a collection is represented by an object containing, among other things, another object named groups, being obviously a list of groups. This is partially wrong, or at least confusing.

Indeed, I was debugging an automation script and noticed this :

  • A call to /public/collections/my-test-id-to-an-existing-and-known-collection send back a properly filled groups property. The result being printed on terminal :
    capture2
    capture21218Ă—34 3.39 KB
  • A call to /public/collections and then filtrating data in order to select only the part relevant to my-test-id-to-an-existing-and-known-collection gives an empty groups (existing but value is None). Here again the result being outputted on terminal :
    capture
    capture780Ă—34 3.39 KB

I blacked out most of the collection ID but of course they are identical in both calls.

I understand very well that the /public/collections method is probably designed to returned a “lite” version of collections in order to make it quicker and the returned data smaller, and I think it is fine as is. However, the API documentation should be enhanced with a warning, in order to avoid letting users figure out themselves why their script is failing on some strange errors such as, in my case :

for group in collection['groups']:
TypeError: 'NoneType' object is not iterable

I hope I described the issue in an understandable way. Also, I wonder if this should be in a different section of this community forum. I don’t feel like it is user-to-user support, as I debugged my own problem (or at least I hope I correctly understand the behaviour of the API here). However it does not sound like a Feature Request nor like a GitHub Contributions thing. Feel free to move this anywhere if best suited.

Best regards

2

Thanks for the post! We’re looking into it.

3

Looks like we have the method stubbed out in the code, so the swagger docs are auto-generating it :sweat_smile:

https://github.com/bitwarden/server/blob/master/src/Api/Public/Controllers/CollectionsController.cs

    {
        var collections = await _collectionRepository.GetManyByOrganizationIdAsync(
            _currentContext.OrganizationId.Value);
        // TODO: Get all CollectionGroup associations for the organization and marry them up here for the response.
        var collectionResponses = collections.Select(c => new CollectionResponseModel(c, null));
        var response = new ListResponseModel<CollectionResponseModel>(collectionResponses);
        return new JsonResult(response);
    }
1 Like
4

So at least the behaviour is normal and expected, I only overthought a bit the “return a “lite” version of collections for performance concerns” thing. Is this on the roadmap for a nearing milestone ?

5

May I ask if this is already planned for a future update ? I’d like to know if I have to rework my synchronization component accounting with this limit, or if I can simply wait for it to be fixed. Currently having 220+ collections to sync, having a single, full-details API call at the beginning of the sync process would be a massive performance improvement compared to having at least one API call for each of the collections