Viktor Koltcov

У меня обычно так: staff - свойство объекта account, поэтому либо вся информация о staff выводится по адресу '/api/account/1', либо там выводится только id, а сам объект staff достается вторым запросом на '/api/staff/x'.

Когда я читал эту книгу, так же завис на данном примере. Вы страницу назад перелистните, там есть пример с созданием данного класса.

Или отойдите подальше или приобретите объектив для макросъемки. Это из простого.
Характеристики объектива какие?

Никак: это не решается стандартными средствами MySQL.
Можно долго и упорно писать многострочные SQL-функции, a можно решить задачу в несколько строк на любом ЯП.

Spring security access control list например
docs.spring.io/spring-security/site/docs/3.0.x/ref...

обычно такие вещи делаются с помощью токенов. т.е. при первом запросе клиент идентифицируется в системе и получает уникальный токен ( число\строка\хеш ) и все последующие сообщения уже отправляет с этим токеном и на его основе определяются его права и возможности.

если есть возможность, я бы глянул в сторону spring-ws и spring-security. они более или менее успешно пытаются предоставить для всего этого удобное апи. и работают почти из коробки. но я сомневаюсь в целесообразности.

Начнем с того что для разработки чего угодно - доступ к счетам не нужен.
Всегда должна быть четко разделена среда для разработки и production.
Где то есть явно тестовые счета, где то можно их сделать.
Соответственно реквизиты для подключения должны задаваться в конфигах и легко меняться при выкладке на боевые сервера.

При этом у Вас остается вопрос наличия в коде закладок (или не преднамеренных уязвимостей) - но стоимость полноценного аудита кода будет сопоставима со стоимостью разработки.

ИМХО, тут есть несколько аспектов:
1. Как написал brainick , математический бэкграунд и английский в data science практически обязателен.
Причин этому несколько: отсутствие хорошей литературы на русском языке (как по теории, так и по программированию), обилие английских терминов (lift/top/cross-validation и прочие), значение которых в переводной литературе порой объяснятся весьма туманно.
2. Если говорить о конкретной литературе, которую стоит почитать, я бы выделил несколько уровней:
Уровень 0
1. Бизнес-аналитика - Паклин, Орешков (самое базовое и обзорное введение)
2. Статистика/Тервер ( по мне, хороши книги Айвазяна/Мхитаряна)
3. SQL - в обязательном порядке. Мне в свое время помогла книга "SQL для простых смертных"
4. Изучаем Python - М. Лутц (наиболее полная книга по языку, все что нужно для data science здесь точно есть)
5. Программируем коллективный разум (к слову сказать, вот в этой книге отличный перевод)
Уровень 1
1. Математические основы машинного обучения и прогнозирования - Вьюгин (книга сложная, без подготовки по учебникам НМУ на тему анализа и линейной алгебры лучше не подходить)
2. Python for Data Analysis (pandas во всей красе, тут нечего добавить)
3. Примеры и статьи по построению моделей в sklearn - на хабре в последнее время часто мелькают статьи на эту тему, там все достаточно хорошо расписано.
Уровень 2
1. Hadoop и иже с ним ("Hadoop в действии", "Programming Pig")
2. Apache Spark - достаточно почитать описание Python API.
Тут есть еще один момент - не стоит слишком привязываться к одному языку и фреймворку.
Одна из неприятных проблем python+pandas+sklearn заключается в том, что эта связка слабо масштабируется - при 2-3-4 гб данных становится сложно разместить их в оперативной памяти. Я знаю про chunk-reading+partial_fit, но точность таких моделей оставляет желать лучшего.
С другой стороны, если обрабатывать эти данные в pyspark, то теряется все удобство pandas.DataFrame и так далее. Отрасль data science быстро развивается и обрастает новыми технологиями, так что нужно все время держать руку на пульсе.
UPD: в spark 1.3 появились DataFrame.