Datamodel is wrong in API documentation

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 :
  • 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 :

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

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

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

        var collections = await _collectionRepository.GetManyByOrganizationIdAsync(
        // 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

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 ?

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