2015-07-24 7 views
0

У меня есть веб-сайт для колледжа, который отслеживает информацию о студентах и ​​обслуживает его до преподавателей факультета, большинство из которых является конфиденциальным. Многие функции на этом сайте включают передачу идентификационного номера ученика в контроллер. Поскольку идентификационные номера учащихся являются конфиденциальными, мне любопытно, могу ли я избежать того, чтобы идентификатор студента отображался в строке URL в качестве параметра. Вот что я исследовал до сих пор:Использование маршрутов RESTful и параметров POST

Вместо того, чтобы передавать идентификатор студента через GET, я мог бы отправить идентификационный номер. Это будет работать нормально, но тогда я смущен тем, как использовать методы RESTful route helper, когда маршрутизатор ожидает запрос GET, и я отправляю запрос POST. Можно ли настраивать вокруг этого?

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

Другая альтернатива, о которой я могу думать, заключается в том, чтобы не использовать остаточные ресурсы вообще. Это вполне выполнимо, но я хочу посмотреть, есть ли другие варианты.

Или есть что-нибудь, о чем я не думаю (очень возможно).

Спасибо,

+0

В случае, если вы можете изменить существующее приложение ... Вы отлично справляетесь с этим способом REST. Вам не нужно возиться с сеансом и хешем внутри него. Предоставление данных этого типа - ** В ЭТОМ СЛУЧАЕ ** - номер идентификатора в качестве параметра строки URL-адреса является плохой практикой. Вместо этого переходите к чему-то, называемому суррогатным ключом - искусственным ориентиром, который является однородным, генерируется, независимо от ученика и не раскрывает личные данные студентов. Для других преимуществ посмотрите на связанную статью wikipedia. https://en.wikipedia.org/wiki/Surrogate_key – adamliesko

ответ

0

Я думаю, вы можете ввести в заблуждение двух различных идей здесь. У ваших учеников может быть уникальный идентификационный номер, чтобы идентифицировать их в образовательной системе или школьных записях, как и National identification number. Но вы не должны/не должны использовать этот номер для идентификации записей в вашем приложении rails.

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

0

Идея REST заключается в использовании каждого из методов, поддерживаемых GET, POST, PUT и DELETE в правильном сценарии.

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

Приветствия

Смежные вопросы