LINUX.ORG.RU

Rest API авторизация и дальнейшее использование, как?

 


0

1

Добрый день!

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

Пользователь сначала авторизируется, потом будет работать с теми прайс-листами на которые имеет доступ. Раньше Rest API не делал, поэтому есть немного тупые вопросы.

Первый вопрос, как авторизоваться правильно? Правильно ли я понимаю, что клиент передаёт логин и пароль пользователя в API, соответственно API проверяет их по базе и если всё нормально, то возвращает некий сгенерированный TOKEN и в дальнейшем клиент каждый свой запрос к API отправляет в месте с данным TOKEN, а API используя данный TOKEN проверяет достоверность пользователя и уже выполняет то что просил пользователь?

Второй вопрос, когда пользователь будет отправлять прайс-лист который объёмом около миллиона строк и занимает примерно 250 мегабайт, то как его отправлять правильно, в виде XML? XML его с тегами ещё увеличит наверное. Стоит как то его ещё разбивать?

Правильно ли я понимаю, что клиент передаёт логин и пароль пользователя в API, соответственно API проверяет их по базе и если всё нормально, то возвращает некий сгенерированный TOKEN

Это аутентификация.

в дальнейшем клиент каждый свой запрос к API отправляет в месте с данным TOKEN, а API используя данный TOKEN проверяет достоверность пользователя

А это уже авторизация.

Ну, в принципе, так оно и работает в общем случае.А в частностях, может быть много ещё интересного.

vvn_black ★★★★ ()

Второй вопрос, когда пользователь будет отправлять прайс-лист который объёмом около миллиона строк и занимает примерно 250 мегабайт

Через REST API такое, наверное, лучше не делать. Проще организовать на стороне клиента добавление к прайсу верификационной информации и делать простой аплоад без API.

vvn_black ★★★★ ()

прайс-лист который объёмом около миллиона строк и занимает примерно 250 мегабайт, то как его отправлять правильно, в виде XML?

правильно его в REST API не отправлять. как ты собираешься обрабатывать ошибки? начиная от сетевых, продолжая ретраем, обработкой дубликатов и ошибками частично успешного импорта? зачем тебе вообще REST в данном случае, если ты не работаешь с отдельными записями через API, а только льешь их миллионами?

anonymous ()
Ответ на: комментарий от vvn_black

А может тогда НУ его этот API и давать пользователям доступ на прямую к базе? На сколько это будет правильно? Я так изначально хотел, но меня отговорили, сказали что чужим доступ давать так не правильно.

А чужие это как раз те кто закачивают прайс-листы, будут их более 300 человек, у каждого свои прайс-листы. Эти люди работают в других организациях и никак не связаны. Но база данных будет правильно ограничена и защищена, всё будет выполняться на функциях, доступа к таблицам не будет. А функции будут проверять права пользователя именно на его данные. Может действительно в данной ситуации не связываться с API, а сделать на прямую?

База кстати PostgreSQL, если я не написал.

LeximusNet ()

Че вы человека пугаете 250мб аплоадом. Оп, ты же понимаешь, что рест апи это просто точки входа в бакенде? Прилетит тебе туда большой боди, ты его разберешь и положишь атомарно в бд, ответишь клиенту, что все ок. Если порвется связь, то закачают заново, проблем-то. Чем «прямой доступ», что бы ты ни имел ввиду под этим, будет лучше?

anonymous ()

Раньше Rest API не делал, поэтому

.. пойми, что в этом больше религии, чем технологии, и делать нужно как тебе удобно. Мы например у себя делаем так: постом в /upload кладется любой большой файл, без знания о том, что это и куда. Возвращается уникальный id. А после этого постом летит например /api (application/json) {method:«update_foo»,params:{pics:[id1,id2],delete_pics:[id3],...}}. Полноценный рест нужен когда ты собираешься интегрироваться с тупорылыми системами, которые были созданы для тех, кто мыслит крудом и на большее не способен. Если от тебя не требуют, то и не ломай голову.

По логину все верно, либо возвращаешь в респонсе токен, который клиент будет приносить в запросах, либо подписанную куку, на случай, когда токен принести не в чем, как в post /upload.

anonymous ()
Ответ на: комментарий от tz4678

JWT
Отдаешь документ частями (чанками) в виде CSV

Плюсую. Сам делал что-то похожее. Только вот с загрузкой прайса ступил и сделал тупо - на сервер грузился файл(но тут как правило не больше 10-15 мб), там на сервере запускался отдельный task, а клиенту возвращался task_id, по которому уже pending статуса загрузки был.

crarkie ()

занимает примерно 250 мегабайт

С одной стророны 250 метров не так уж много, но я бы прикрутил какой-нить nginx-big-upload и грузил твой файл частями. Поможет юзерам на нестабильном канале.

По окончанию загрузки можно скармливать токен от загруженного файла сервису чтобы он его прожевал.

ya-betmen ★★★★★ ()

все 300 пользователей используют свои программы, которые должны подключаться к вашему API ?
Или можно дать им всем одну программу, которая уже сама все куда надо загрузит по ей одной известному протоколу ?
Нельзя сделать просто сайт, а там юзеры вручную вводят, или загружают файл ?

Serik ()