Данный проект направлен на создание гибкой серверной инфраструктуры для разработки и обслуживания корпоративных аккаунтов в WeChat и WeChat Work.

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

• участников;
• отделы;
• метки;
• сообщения;
• авторизацию приложений;
• OAuth2.0;
• меню приложений;
• файлы;
• платежи и т. д. Однако он не будет реализовывать интерфейсы авторизации сторонних приложений.

Требования к системе:

1. Linux CentOS или Ubuntu.
2. Nginx версии 1.4.7 или выше.
3. PHP версии 5.5 или выше.
4. Swoole версии 1.8.x.
5. YAF версии 2.3.4 или выше, а при использовании PHP7 рекомендуется использовать последнюю версию YAF 3.0.4.
6. SeasLog версии 1.6.2 или выше.
7. Redis версии 3.0.3.
8. MariaDB версии 10.1.17.

Правила кодирования:

1. В случаях, когда это не противоречит правилам YAF, следует придерживаться PSR-стандартов кодирования.
2. Все ошибки должны быть выброшены с помощью throw new \Exception();
3. Коды ошибок: при возникновении ошибки необходимо различать уровни ошибок, код ошибки состоит из «одного идентификатора уровня ошибки (отличающегося от 5-значного кода WeChat)» + «три цифры кода ошибки». Идентификаторы соответствуют 8 уровням журнала SeasLog (debug, info, notice, warning, error, critical, alert, emergency). Например, 8456 — это уровень ошибки emergency.
4. Журналы: хотя можно отдельно выводить журналы ошибок в контроллере ошибок, журналы не могут записывать некоторую ключевую информацию о месте, поэтому следует выводить журналы в коде в соответствии с бизнес-требованиями, чтобы обеспечить здоровое предупреждение и анализ с помощью SeasLog.
5. Следует разделить модули по функциям, каждый модуль должен иметь как минимум три контроллера:
   • Контроллер индекса: реализация интерфейса управления бэкендом, рендеринг страниц и выполнение некоторых операций управления и переходов.
   • Api-контроллер: предоставление api, доступного для вызова модулем.
   • Error-контроллер: централизованная обработка ошибок.
6. Интерфейс возврата: данные возвращаются в формате JSON по умолчанию, например: {"code":0,"msg":"success","data":"data"}, где код равен 0, что указывает на успешное выполнение, данные находятся в поле data, в противном случае код является кодом ошибки, а msg — сообщением об ошибке. Все возвращаемые данные API-интерфейсов могут быть упакованы с использованием функции packing().
7. Все API-интерфейсы должны указывать параметры запроса и другие необходимые пояснения. Если есть вклад исходного кода, необходимо написать страницу документа wiki с именем модуля или компонента.
8. Контроллеры не должны содержать слишком много бизнес-кода, они служат только в качестве точек входа. Для удобства расширения и общего контроля предусмотрены три предопределённых контроллера: Api, Web и Error. Все контроллеры, предоставляющие API, должны наследовать system\controllers\Api, все контроллеры, обеспечивающие доступ к веб-страницам, должны наследовать system\controllers\Web, а все контроллеры ошибок должны наследовать system\controllers\Error.

Соглашения об интерфейсах и параметрах:

1. Интерфейсы используют стиль RESTful, и для удобства и простоты использования по умолчанию используется статический маршрут Yaf. Используйте методы getParam() или getParams() слоя контроллера для получения данных, если имеется только один неполный параметр маршрута, этот параметр будет заполнен в поле id набора параметров, если есть полный параметр маршрута, параметры маршрута будут объединены в параметры формы, и параметры формы будут иметь приоритет. Например, http://w.wcdf.com/member/api/departments/1, если данные формы — name=имя&id=2, то данные, полученные методом getParams(), будут array('name'=>'имя',id=>1), то есть можно не указывать параметр id в форме, а добавить его после URL, что также является рекомендуемым подходом. При других условиях, для http://w.wcdf.com/member/api/departments/id/1 данные будут array('name'=>'имя',id=>2). Соответствующий код см. в application/library/system/controllers/Base.php.
2. Обратите особое внимание на то, что данные интерфейса должны быть унифицированы с использованием x-www-from-urlencoded вместо multipart/form-data, за исключением случаев, когда выполняются специальные операции, такие как загрузка файлов, иначе данные не будут получены, особенно при тестировании интерфейсов с помощью таких инструментов, как Postman.
3. Как правило, каждый ресурс интерфейса должен реализовывать как минимум GET, POST, PUT и DELETE запросы, основываясь на фактической реализации интерфейса и требованиях.

Вспомогательные проекты:

Для обработки асинхронных задач предоставляется асинхронный обработчик задач на основе nsq в качестве очереди сообщений и swoole в качестве потребителя сообщений. См. swoole-nsq (http://git.oschina.net/tttlkkkl/swoole-nsq).

Прочее:

См. wiki (https://git.oschina.net/tttlkkkl/wcdf/wikis/home).