Эта логика (я работаю для Spotify): требуя от наших разработчиков перепрыгнуть через кучу обручей, чтобы получить их ключ API в их двоичный файл, не будет стоить того - разработчики будут отключены им и все будут несчастны.
Однако мы не хотим, чтобы клавиши были распространены вокруг, просто потому что, если каждый использует один ключ, мы не можем надежно отслеживать его, и если этот ключ в конечном итоге используется для чего-то злонамеренного, и мы его убиваем, много приложений внезапно будет нарушена.
Чтобы заставить себя испытать ужасную аналогию с автомобилем, представьте, что ключ API - это ценный предмет, и ваше приложение - это автомобиль. Если вы оставите элемент на сиденье автомобиля (т. Е. Имея свой ключ API в виде обычного текста), вы практически приглашаете кого-то вломиться и украсть его (т. Е. Использовать свой ключ в своем собственном приложении). Если вы положите его в перчаточный ящик (скомпилируйте его в свой бинарный файл), если кто-то перерыл ваш автомобиль (разобрал ваше приложение), потому что он знает, что предмет находится в перчаточном ящике, это в значительной степени игра в любом случае.
Вкратце: компиляция ключа является абсолютно безопасным с помощью неизвестности, но мы считаем, что этого достаточно, чтобы отговорить людей от случайного повторного использования ключей API других приложений, когда это довольно тривиально, чтобы получить от нас прямо.
Я предполагаю, что суть моего вопроса такова: как я могу избежать нарушения ToS, не требуя от каждого пользователя получить свой собственный ключ?
Если вы распространяете свое приложение в двоичной форме, компиляция его в порядке. Если вы распространяете его в исходной форме, вы не можете включить ключ.
Этот вопрос не соответствует теме, поскольку речь идет о Условиях обслуживания. Только вопросы о spotify api по теме. – quetzalcoatl