We need to wait with merging this PR until we release v2.0.0.

I've updated this branch, the merge conflicts were quite complex due to the refactoring we did while this PR was already out.

Currently, there's a typing issue:

    @classmethod
    def _get_slice(cls, request: Request, iterator: Iterable[T]) -> Tuple[Iterator[T], int]:
        limit_str = request.args.get('limit', default="10")
        cursor_str = request.args.get('cursor', default="1")
        try:
            limit, cursor = int(limit_str), int(cursor_str) - 1  # cursor is 1-indexed
            if limit < 0 or cursor < 0:
                raise ValueError
        except ValueError:
            raise BadRequest("Limit can not be negative, cursor must be positive!")
        start_index = cursor
        end_index = cursor + limit
        items = list(itertools.islice(iterator, start_index, end_index + 1))
        has_more = len(items) > limit
        paginated_slice = iter(items[:limit])
        next_cursor = cursor + limit if has_more else None
        return paginated_slice, next_cursor

As it is implemented, it actually returns Optional[int] with next_cursor.
However, the endpoints that use this method do expect int.
Someone more experienced with the API spec should investigate how this method is supposed to behave and what we need to adapt.

Furthermore, @moritzsommer, could you review the repository.py file w.r.t. the ObjectStore refactor please?

I did some research and found:

Constraint AASa-001: The value of the cursor query parameter must not be empty. If the client does not know the cursor value, it must omit the whole query parameter in the request.

But this is with regards to how the client needs to form the request, not how the server needs to respond.

The pagination of results as defined in AAS Part 2, "Pagination" uses the cursor parameter in requests for defining the position from which to resume the results in the next request. The required value is obtained from a previous paginated result, containing a paging_metadata which is defined in the specs as follows:

In the server implementation all logic in handling the cursor value is encapsulated in the _get_slice(...) method. Every endpoint implementation that invokes this method at some point, passes the value of next_cursor unmodified to the cursor parameter in the APIResponse constructor, which is typed Optional[int].

Therefore I suggest to adapt the return type of _get_slice(...) (as well as all other methods that depend on it) to Tuple[Iterator[T], Optional[int]].

Despite that, I want to point out that the current implementation of _get_slice(...) is incorrect, as the returned next_cursor value is too low by 1 (due to the 1-based indexing). Additionally, the AAS Spec Part 2, defines the default value of the limit request parameter to be 100 rather than 10.