Пользовательская система руководства по дизайну электронной коммерции

задняя часть WeChat продукт Интерактивный дизайн

предисловие

Я занимаюсь разработкой интернет-торговли уже более трех лет, оглядываясь назад, я мало что знаю обо всем бизнес-процессе, мне стыдно об этом говорить. Однако в среде интернет-электронной коммерции я более-менее контактирую с различными бизнесами, а вокруг много коллег и друзей, которые занимаются электронной коммерцией, а это все ресурсы. Итак, я решил разобраться во всем процессе и поделиться им с коллегами, друзьями и даже с вами.Я не могу говорить о том, насколько хорошие результаты, по крайней мере, везде, где у нас есть возможность сделать хорошо, мы будем однозначно нюанс.

Кроме того, чтобы удовлетворить техническое удовлетворение, которое мы можем не получить в нашей собственной работе, мы будем использовать стек технологий, который мы больше всего хотим использовать в процессе проектирования всей системы. Мы используем докер для достижения стека технологий, поэтому конечный результат: с одной стороны, мы освоили дело, а с другой стороны, получили техническое удовлетворение, а можно и то, и другое.

Наконец, ради времени, мы придумали идеюDo design No code. **[Только проектирование без кодирования]** Смысл этого предложения: В итоге мы спроектировали модель данных всей системы, интерфейсные документы, даже процесс взаимодействия, развертывание среды и т. д., но в итоге мы код не писал. правильно? Если да, то какой смысл писать код. Конечно, это не все, конечно, это будет реализовано в коде из соображений времени, может быть, наоборот, вы, в конце концов, это реализуете.

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

Сегодня начинаем первую частьПользовательская системадизайн. Этот документ разделен на следующие четыре модуля:

  • Архитектурный дизайн
  • дизайн модели данных
  • Интерактивный дизайн
  • дизайн интерфейса

Архитектурный дизайн

Простой взгляд на пользовательскую систему

Когда вы впервые соприкоснулись с интернет-продуктами, связанными с пользователями, это было в моих глазах.Пользовательская системаНе более, чем «войти» и «зарегистрироваться», «изменить информацию о пользователе» и так далее. Чтобы сделать это просто, нам просто нужна таблица для записи идентификационной информации пользователя: при регистрации (операция вставки) вставьте данные в таблицу; при входе в систему (операция выбора и обновления) судите по идентификатору пользователя (номер мобильного телефона, адрес электронной почты, и т. д.) Является ли пароль пользователя правильным; изменение информации о пользователе (операция select&update) заключается в непосредственном обновлении информации о пользователе (аватар, псевдоним и т. д.) этого uid.

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

Что должна иметь базовая пользовательская система

Во-первых, мы снова абстрагируем исходную таблицу пользователей (извлекаем регистрацию пользователя, поля, зависящие от входа, сторонний вход) ->Таблица счетов, зачем это делать? С развитием бизнеса мы привыкли поддерживать только один продукт и, возможно, однажды разработаем новый продукт, чтобы мы могли поддерживать логику регистрации и входа в систему для всех продуктов нашей компании единообразно.Разные продукты поддерживают только информацию, связанную с продукт и пользователь, а именно Да (в зависимости от формы продукта). Как показано ниже:

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

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

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

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

окончательная архитектура

Поскольку формы бизнес-продуктов становятся все более и более сложными, при проектировании архитектуры нам необходимо анализироватьменяй и меняй:

  • Изменения: все больше и больше продуктов персонализируются в соответствии с потребностями пользователей.
  • То же: логика регистрации и входа

В конце концов, мы разделили первоначальных пользователей наСчетиПользователь, в то же время мы также хотим уточнить разницу между этими двумя понятиями здесь:

  • Учетная запись: единственное место во всей системе, где создается uid, с согласованной логикой регистрации и входа в систему и не связанное с бизнес-требованиями продукта.
  • Пользователи: персонализированная информация о спросе пользователей на различные продукты.

Окончательная схема архитектуры выглядит следующим образом:

  • Часть 1: Аккаунт (сервисный уровень)
  • Часть II: Пользователь (прикладной уровень, бесконечное горизонтальное расширение)
  • Часть III: Сотрудники (прикладной уровень, система полномочий сотрудников)

дизайн модели данных

В соответствии с приведенной выше архитектурой мы можем легко спроектировать нашу модель данных (здесь предполагается, что в настоящее время у нас есть только одно приложение на стороне C):

账户 -> 1.账户表
用户 -> 2.用户表
员工 -> 3.员工表

В дополнение к приведенным выше трем таблицам нам также понадобится управление правами R (роль) B (базовый) A (доступ) C (управление). Все должны быть знакомы с управлением правами на основе ролей RBAC. Я не буду вдаваться в подробности. здесь просто RBAC сначала требует:

4.系统菜单表(菜单即权限)，系统的uri路径
5.权限表(菜单即权限)，具体的权限就是访问系统的菜单
6.角色表，一个角色具有哪些权限
7.员工和角色的关联表，一个员工属于哪个角色

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

8.后台管理系统表, 登记所有的后台管理系统(这样通过系统id和系统资源uri的id就可以全局构成唯一性，单纯的uri存在重复的可能性，用uri不用url的原因是域名存在变动的可能性)

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

9. 第三方用户登陆表，记录不同第三方的用户标示

Наконец, есть приведенные выше таблицы 9. Конкретная структура таблицы и sql следующие:

таблица sql

Модель аккаунта


-- 账户模型
CREATE TABLE `account_user` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '账号id',
  `email` varchar(30) NOT NULL DEFAULT '' COMMENT '邮箱',
  `phone` varchar(15) NOT NULL DEFAULT '' COMMENT '手机号',
  `username` varchar(30) NOT NULL DEFAULT '' COMMENT '用户名',
  `password` varchar(32) NOT NULL DEFAULT '' COMMENT '密码',
  `create_at` int(11) NOT NULL DEFAULT '0' COMMENT '创建时间',
  `create_ip_at` varchar(12) NOT NULL DEFAULT '' COMMENT '创建ip',
  `last_login_at` int(11) NOT NULL DEFAULT '0' COMMENT '最后一次登陆时间',
  `last_login_ip_at` varchar(12) NOT NULL DEFAULT '' COMMENT '最后一次登陆ip',
  `login_times` int(11) NOT NULL DEFAULT '0' COMMENT '登录次数',
  `status` tinyint(1) NOT NULL DEFAULT '0' COMMENT '状态 1:enable, 0:disable, -1:deleted',
  PRIMARY KEY (`id`),
  KEY `idx_email` (`email`),
  KEY `idx_phone` (`phone`),
  KEY `idx_username` (`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='账户';

-- 第三方账户
CREATE TABLE `account_platform` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增id',
  `uid` int(11) unsigned NOT NULL DEFAULT '0' COMMENT '账号id',
  `platform_id` varchar(60) NOT NULL DEFAULT '' COMMENT '平台id',
  `platform_token` varchar(60) NOT NULL DEFAULT '' COMMENT '平台access_token',
  `type` tinyint(1) NOT NULL DEFAULT '0' COMMENT '平台类型 0:未知,1:facebook,2:google,3:wechat,4:qq,5:weibo,6:twitter',
  `nickname` varchar(60) NOT NULL DEFAULT '' COMMENT '昵称',
  `avatar` varchar(255) NOT NULL DEFAULT '' COMMENT '头像',
  `create_at` int(11) NOT NULL DEFAULT '0' COMMENT '创建时间',
  `update_at` int(11) NOT NULL DEFAULT '0' COMMENT '更新时间',
  PRIMARY KEY (`id`),
  KEY `idx_uid` (`uid`),
  KEY `idx_platform_id` (`platform_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='第三方用户信息';

Пользовательская модель


-- 用户模型
CREATE TABLE `skr_member` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '用户id',
  `uid` int(11) unsigned NOT NULL DEFAULT '0' COMMENT '账号id',
  `nickname` varchar(30) NOT NULL DEFAULT '' COMMENT '昵称',
  `avatar` varchar(255) NOT NULL DEFAULT '' COMMENT '头像(相对路径)',
  `gender` enum('male','female','unknow') NOT NULL DEFAULT 'unknow' COMMENT '性别',
  `role` tinyint(1) unsigned NOT NULL DEFAULT '0' COMMENT '角色 0:普通用户 1:vip',
  `create_at` int(11) NOT NULL DEFAULT '0' COMMENT '创建时间',
  `update_at` int(11) NOT NULL DEFAULT '0' COMMENT '更新时间',
  PRIMARY KEY (`id`),
  KEY `idx_uid` (`uid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='账户信息';

модель сотрудника


-- 员工表
CREATE TABLE `staff_info` (
    `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '员工id',
    `uid` int(11) unsigned NOT NULL DEFAULT '0' COMMENT '账号id',
    `email` varchar(30) NOT NULL DEFAULT '' COMMENT '员工邮箱',
    `phone` varchar(15) NOT NULL DEFAULT '' COMMENT '员工手机号',
    `name` varchar(30) NOT NULL DEFAULT '' COMMENT '员工姓名',
    `nickname` varchar(30) NOT NULL DEFAULT '' COMMENT '员工昵称',
    `avatar` varchar(255) NOT NULL DEFAULT '' COMMENT '员工头像(相对路径)',
    `gender` enum('male','female','unknow') NOT NULL DEFAULT 'unknow' COMMENT '员工性别',
    `create_at` int(11) NOT NULL DEFAULT '0' COMMENT '创建时间',
    `update_at` int(11) NOT NULL DEFAULT '0' COMMENT '更新时间',
    PRIMARY KEY (`id`),
    KEY `idx_uid` (`uid`),
    KEY `idx_email` (`email`),
    KEY `idx_phone` (`phone`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='员工信息(这里列了大概的信息，多的可以垂直拆表)';

Модель управления системными правами


-- 权限管理: 系统map
CREATE TABLE `auth_ms` (
    `id` smallint(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增id',
    `ms_name` varchar(255) NOT NULL DEFAULT '0' COMMENT '系统名称',
    `ms_desc` varchar(255) NOT NULL DEFAULT '0' COMMENT '系统描述',
    `ms_domain` varchar(255) NOT NULL DEFAULT '0' COMMENT '系统域名',
    `create_at` int(11) NOT NULL DEFAULT '0' COMMENT '创建时间',
    `create_by` int(11) NOT NULL DEFAULT '0' COMMENT '创建人staff_id',
    `update_at` int(11) NOT NULL DEFAULT '0' COMMENT '更新时间',
    `update_by` int(11) NOT NULL DEFAULT '0' COMMENT '修改人staff_id',
    `status` tinyint(1) NOT NULL DEFAULT '0' COMMENT '状态 1:enable, 0:disable, -1:deleted',
    PRIMARY KEY (`id`),
    KEY `idx_domain` (`domain`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='系统map(登记目前存在的后台系统信息)';

-- 权限管理: 系统menu
CREATE TABLE `auth_ms_menu` (
    `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增id',
    `ms_id` smallint(11) unsigned NOT NULL DEFAULT '0' COMMENT '系统id',
    `parent_id` int(11) unsigned NOT NULL DEFAULT '0' COMMENT '父菜单id',
    `menu_name` varchar(255) NOT NULL DEFAULT '0' COMMENT '菜单名称',
    `menu_desc` varchar(255) NOT NULL DEFAULT '0' COMMENT '菜单描述',
    `menu_uri` varchar(255) NOT NULL DEFAULT '0' COMMENT '菜单uri',
    `create_at` int(11) NOT NULL DEFAULT '0' COMMENT '创建时间',
    `is_show` enum('yes','no') NOT NULL DEFAULT 'no' COMMENT '是否展示菜单',
    `create_by` int(11) NOT NULL DEFAULT '0' COMMENT '创建人staff_id',
    `update_at` int(11) NOT NULL DEFAULT '0' COMMENT '更新时间',
    `update_by` int(11) NOT NULL DEFAULT '0' COMMENT '修改人staff_id',
    `status` tinyint(1) NOT NULL DEFAULT '0' COMMENT '状态 1:enable, 0:disable, -1:deleted',
    PRIMARY KEY (`id`),
    KEY `idx_ms_id` (`ms_id`),
    KEY `idx_parent_id` (`parent_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='系统menu';

-- 权限管理: 系统权限
CREATE TABLE `auth_item` (
    `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增id',
    `ms_id` tinyint(11) unsigned NOT NULL DEFAULT '0' COMMENT '系统id',
    `menu_id` varchar(255) NOT NULL DEFAULT '0' COMMENT '页面/接口uri',
    `create_at` int(11) NOT NULL DEFAULT '0' COMMENT '创建时间',
    `create_by` int(11) NOT NULL DEFAULT '0' COMMENT '创建人staff_id',
    `update_at` int(11) NOT NULL DEFAULT '0' COMMENT '更新时间',
    `update_by` int(11) NOT NULL DEFAULT '0' COMMENT '修改人staff_id',
    `status` tinyint(1) NOT NULL DEFAULT '0' COMMENT '状态 1:enable, 0:disable, -1:deleted',
    PRIMARY KEY (`id`),
    KEY `idx_ms_menu` (`ms_id`, `menu_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='系统权限';

-- 权限管理: 系统权限(权限的各个集合)
CREATE TABLE `auth_role` (
    `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增id',
    `name` varchar(255) NOT NULL DEFAULT '0' COMMENT '角色名称',
    `desc` varchar(255) NOT NULL DEFAULT '0' COMMENT '角色描述',
    `auth_item_set` text COMMENT '权限集合 多个值,号隔开',
    `create_at` int(11) NOT NULL DEFAULT '0' COMMENT '创建时间',
    `create_by` int(11) NOT NULL DEFAULT '0' COMMENT '创建人staff_id',
    `update_at` int(11) NOT NULL DEFAULT '0' COMMENT '更新时间',
    `update_by` int(11) NOT NULL DEFAULT '0' COMMENT '修改人staff_id',
    `status` tinyint(1) NOT NULL DEFAULT '0' COMMENT '状态 1:enable, 0:disable, -1:deleted',
    PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='员工角色';

-- 权限管理: 角色与员工关系
CREATE TABLE `auth_role_staff` (
    `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增id',
    `staff_id` int(11) unsigned NOT NULL DEFAULT '0' COMMENT '员工id',
    `role_set` text COMMENT '角色集合 多个值,号隔开',
    `create_at` int(11) NOT NULL DEFAULT '0' COMMENT '创建时间',
    `create_by` int(11) NOT NULL DEFAULT '0' COMMENT '创建人staff_id',
    `update_at` int(11) NOT NULL DEFAULT '0' COMMENT '更新时间',
    `update_by` int(11) NOT NULL DEFAULT '0' COMMENT '修改人staff_id',
    `status` tinyint(1) NOT NULL DEFAULT '0' COMMENT '状态 1:enable, 0:disable, -1:deleted',
    PRIMARY KEY (`id`),
    KEY `idx_staff_id` (`staff_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='权限角色与员工关系';

Интерактивный дизайн

Дружеское напоминание: идет большая волна фотографий, здесь есть еще фотографии, если вам не ясно, вы можете нажать на большую картинку, чтобы просмотреть

регистр

После успешной регистрации есть как минимум два способа взаимодействия:

  1. Успешная регистрация -> перейти на страницу входа
  2. Успешная регистрация -> автоматический вход -> переход на домашнюю страницу приложения (или другие страницы)

Конкретный процесс взаимодействия выглядит следующим образом:

авторизоваться

Быстрый вход

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

сторонний логин

Взаимодействие стороннего логина на самом деле имеет следующие проблемы:

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

Потому что я обнаружил, что некоторые личные сообщения, чтобы улучшить простоту и скорость использования пользователями, часто генерируют uid сразу после успешного входа в стороннюю систему, без привязки учетной записи. После этого привязка аккаунта будет включать объединение аккаунтов, что очень хлопотно (при наличии кошелька и т.п.). Если мы выполним операцию привязки с самого начала, отношения между будущими учетными записями будут понятными и простыми в обслуживании, а сторонний вход фактически эквивалентен псевдониму обычной учетной записи. В конце концов, результатом этого является то, что таблица учетных записей account_user и сторонняя таблица информации о пользователях account_platformодин ко многимвсе ещеодин на одинОтношение.

  1. Если привязан, можно ли привязать зарегистрированный номер мобильного телефона/электронную почту?

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

Схема интерактивного интерфейса выглядит следующим образом:

Фоновое управление разрешениями

Прежде всего, наша система управления фоном нуждается в громком названии.Поразмыслив некоторое время, компания использовала apollo, поэтому я собирался использовать mars, но вдруг земля, корень всего на земле, случилась. быть основой всего нашего бизнеса Система управления услугами, ха-ха, вот и все~Earth System

Earth SystemФункция управления правами системы в основном разделена на следующие четыре части:

  • Управление системой (страница управления управлением)
    • отредактируйте страницу
    • страница со списком
  • Страница меню
    • отредактируйте страницу
    • страница со списком
  • Управление ролями (страница ролей)
    • отредактируйте страницу
    • страница со списком
  • Управление персоналом и ассоциациями ролей (страница карты персонала ролей)
    • отредактируйте страницу
    • страница со списком

Конкретные взаимодействия заключаются в следующем:

дизайн интерфейса

Интерфейс прикладного уровня (внешний)

1. Регистрационный интерфейс

Параметры запроса:

поле тип Это обязательно описывать
username string не требуется учетная запись пользователя
email string электронная почта/телефон альтернатива Почтовый ящик пользователя
phone string электронная почта/телефон альтернатива Номер мобильного телефона пользователя
code int должен пройти код верификации

Первый режим взаимодействия (переход на целевую страницу) содержание ответа:

{
    "code": "200",
    "msg": "OK",
    "result": []
}

Режим взаимодействия 2 (переход на главную страницу) содержание ответа:

{
    "code": "200",
    "msg": "OK",
    "result": {
        "s_token": "string, 用户会话标示",
        "s_token_expire": "string, 用户会话标示过期时间，0不过期",
        "username": "string, 用户名",
        "nickname": "string, 用户昵称",
        "avatar": "string, 用户头像",
        "gender": "string, 用户性别，male:男，female:女，other:未知",
    }
}

2. Интерфейс входа

Параметры запроса:

поле тип Это обязательно описывать
username string Выберите одно из имени пользователя/электронной почты/телефона учетная запись пользователя
email string Выберите одно из имени пользователя/электронной почты/телефона Почтовый ящик пользователя
phone string Выберите одно из имени пользователя/электронной почты/телефона Номер мобильного телефона пользователя
password string должен пройти пароль

Содержание ответа:

{
    "code": "200",
    "result": {
        "s_token": "string, 用户会话标示",
        "s_token_expire": "string, 用户会话标示过期时间，0不过期",
        "nickname": "string, 用户昵称",
        "username": "string, 用户名",
        "avatar": "string, 用户头像",
        "gender": "string, 用户性别，male:男，female:女，other:未知",
    }
}

3. быстрый вход в интерфейсы

Параметры запроса:

поле тип Это обязательно описывать
email string электронная почта/телефон альтернатива Почтовый ящик пользователя
phone string электронная почта/телефон альтернатива Номер мобильного телефона пользователя
code int должен пройти код верификации

Содержание ответа:

{
    "code": "200",
    "result": {
        "s_token": "string, 用户会话标示",
        "s_token_expire": "string, 用户会话标示过期时间，0不过期",
        "nickname": "string, 用户昵称",
        "username": "string, 用户名",
        "avatar": "string, 用户头像",
        "gender": "string, 用户性别，male:男，female:女，other:未知",
    }
}

4. Сторонний интерфейс входа в систему

Параметры запроса:

поле тип Это обязательно описывать
type string должен пройти Тип платформы 1: facebook, 2: google, 3: wechat, 4: qq, 5: weibo, 6: twitter.
platform_id string должен пройти Идентификатор пользователя сторонней платформы
platform_token string должен пройти Токены сторонних платформ

Содержание ответа:

{
    "code": "200",
    "result": {
        "s_token": "string, 用户会话标示",
        "s_token_expire": "string, 用户会话标示过期时间，0不过期",
        "username": "string, 用户名",
        "nickname": "string, 用户昵称",
        "avatar": "string, 用户头像",
        "gender": "string, 用户性别，male:男，female:女，other:未知",
    }
}

5. Интерфейс модификации пользовательской информации

Параметры запроса:

поле тип Это обязательно описывать
username string не требуется учетная запись пользователя
nickname string не требуется Никнейм
avatar string не требуется адрес аватара
gender string не требуется Пол пользователя, мужской: мужской, женский: женский, другое: неизвестно

Содержание ответа:

{
    "code": "200",
    "result": {
        "username": "string, 用户名",
        "nickname": "string, 用户昵称",
        "avatar": "string, 用户头像",
        "gender": "string, 用户性别，male:男，female:女，other:未知",
    }
}

6. Проверка статуса входа пользователя

Параметры запроса:

поле тип Это обязательно описывать
s_token string должен пройти Идентификатор сеанса пользователя

Содержание ответа:

{
    "code": "200",
    "result": {
        "s_token_expire": "string, 用户会话标示过期时间，0不过期， -1登陆失效",
    }
}

Сервисный интерфейс (базовый сервис, внутренний)

Услуги по работе с аккаунтом:

  1. регистр

Параметры запроса:

поле тип Это обязательно описывать
username string не требуется учетная запись пользователя
email string электронная почта/телефон альтернатива Почтовый ящик пользователя
phone string электронная почта/телефон альтернатива Номер мобильного телефона пользователя

Первый режим взаимодействия (переход на целевую страницу) содержание ответа:

{
    "code": "200",
    "msg": "OK",
    "result": {
        "uid": "string, 账户ID"
    }
}
  1. авторизоваться

Параметры запроса:

поле тип Это обязательно описывать
username string не требуется учетная запись пользователя
email string электронная почта/телефон альтернатива Почтовый ящик пользователя
phone string электронная почта/телефон альтернатива Номер мобильного телефона пользователя
password string должен пройти пароль

Содержание ответа:

{
    "code": "200",
    "msg": "OK",
    "result": {
        "uid": "string, 账户ID"
    }
}
  1. Войти в систему с

Параметры запроса:

поле тип Это обязательно описывать
type string должен пройти Тип платформы 1: facebook, 2: google, 3: wechat, 4: qq, 5: weibo, 6: twitter.
platform_id string должен пройти Идентификатор пользователя сторонней платформы
platform_token string должен пройти Токены сторонних платформ

Содержание ответа:

{
    "code": "200",
    "result": {
        "uid": "string, 账户ID",
        "nickname": "string, 用户昵称",
        "avatar": "string, 用户头像",
    }
}

Служба разрешений

  1. получить системное меню

Параметры запроса:

поле тип Это обязательно описывать
ms_id string должен пройти Идентификатор системы

Содержание ответа:

{
    "code": "200",
    "msg": "OK",
    "result": {
        "ms_name": "string, 系统名称",
        "ms_desc": "string, 系统描述",
        "ms_domain": "string, 系统域名",
        "list": [
            {
                "parent_id": "string, 父菜单ID",
                "menu_id": "string, 菜单ID",
                "menu_name": "string, 菜单ID",
                "menu_desc": "string, 菜单描述",
                "menu_uri": "string, 菜单uri",
                "child" : [
                    {
                        "parent_id": "string, 父菜单ID",
                        "menu_id": "string, 菜单ID",
                        "menu_name": "string, 菜单ID",
                        "menu_desc": "string, 菜单描述",
                        "menu_uri": "string, 菜单uri",
                        "child" : []
                    }
                ]
            }
        ]
    }
}
  1. проверка разрешений

Параметры запроса:

поле тип Это обязательно описывать
menu_id string должен пройти идентификатор меню

Содержание ответа:

{
    "code": "200",
    "msg": "OK",
    "result": []
}

Эпилог

Если в тексте есть что-то неправильное или несовершенное, я надеюсь, что вы будете больше комментировать, учиться друг у друга и улучшать друг друга~

адрес проекта:GitHub.com/payee-shop/лошадь…

Краткое представление участников проекта skr-shop

В произвольном порядке, в лексикографическом порядке

Никнейм Введение личный блог
AStraw Дипломированный предприниматель, в настоящее время занимается внутренними исследованиями и разработками торгового центра в Xiaomi Technology Overseas Mall Group. --------
Даю PHP сторонний проект агрегации платежей, используемый большинством людей в КитаеPaymentАвтор, предприниматель, в настоящее время занимается внутренними исследованиями и разработками торгового центра в Xiaomi Technology Overseas Mall Group. Дайу Ток
lwhcv Работал в Baidu/Rong 360, а сейчас занимается внутренними исследованиями и разработками торгового центра в Xiaomi Technology Overseas Mall Group. --------
TIGERB PHP-фреймворкEasyPHPАвтор имеет опыт работы в раундах A/B/C стартапов электронной коммерции и в настоящее время занимается внутренними исследованиями и разработками торгового центра в Xiaomi Technology Overseas Mall Group. TIGERB.cn

Категории