Как поделить api на части с различным функционалом?

Василий Банников,

Только одну ссылку*.

Я не имею в виду конкретно данный случай. APIPart вполне может содержать другие данные, кроме ссылок.

Пока лучшее, что я придумал это заприватить APIPart в API и сделать на него геттер.

pub struct API<'a> {
        api_key: Box<String>,
        part: APIPart<'a>,
    }
    
    impl API<'_> {
        pub fn new(api_key: &str) -> Self {
            let api_key = Box::new(api_key.to_owned());
            let part = APIPart::new(&*api_key);
            
            return Self {
                api_key,
                part,
            };
        }
        
        pub fn part(&self) -> &APIPart {
            return &self.part;
        }
    }

Хотя это не идеально, если в APIPart будут данные которые нужно будет мутировать, то понадобится еще метод типа part_mut().

Ещё вариант - не вводить ApiPart вообще и сделать разбиение при помощи трейтов

Не совсем понимаю, что конкретно имеется в виду.
Если просто

trait APIPart {
    //...
}

impl APIPart for API {
    //...
}

то это не вариант.
Весь смысл APIPart как раз в том, чтобы сгруппировать одинаковую по смыслу логику.
А так все методы будут напрямую в API.

Как поделить api на части с различным функционалом?

По факту создание ApiPart эквивалентно просто возврату ссылки на api_key - чистейший зеро кост, в чём можно убедиться, посмотрев на листинг.

Это может и так, если APIPart будет содержать только ссылки, но это не гарантированно.

Не стоит это делать через поля как минимум из-за того что ты так N раз будешь копировать ссылку.

О каких N раз идет речь? Имеешь в виду, если будет N разных APIPart?

Как поделить api на части с различным функционалом?

В идеале я бы хотел именно через поля, ЕСЛИ такое возможно.
Если нет, ну что же буду писать скобки каждый раз.
Тем не менее твой вариант я думаю не особо мне подходит, потому что при вызове part() будет каждый раз создаваться новый APIPart.
Почему можно передавать APIPart в другой поток я вроде разобрался, я просто неправильно понимал лайфтаймы:

pub struct API<'a> {
    pub part: APIPart<'a>,
}

В данном случае lifetime(API) <= lifetime(APIPart), а я почему то считал, что наоборот.

Алгоритм максимально равномерного распределения предметов?

Василий Банников, все верно

Как проверить внешний ключ?

У меня предполагается, что, допустим, кол-во часов по предмету может измениться именно в конкретной группе, поэтому предмет привязан к группе. Но не суть, даже если делать по другому, то проблема все равно остается.

То есть, к примеру, студент из группы 1 может сдавать задание, которое было выдано группе 2.