Создание версий API для моего php-приложения (приложение для социальных сетей) - PullRequest
Новая
       11

Создание версий API для моего php-приложения (приложение для социальных сетей)

7 голосов
/ 29 мая 2019

В настоящее время я работаю над социальным приложением.

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

Допустим, мое приложение v1.0.Затем я создаю новую версию v2.0 и, конечно, я тоже обновляю файлы PHP.После этого, если кто-то не обновил свое приложение с версии 1.0, я бы хотел, чтобы оно достигло myapp.com/v1.0/, чтобы приложение не зависало.

Что бы вы порекомендовали?

Типичный мой PHP-файл выглядит следующим образом, например: 

<?php

// Include files

include_once ('../../config.php');

include_once (ROOT_DIR . '/config/includes.php');

$_USERDATA = Validator::validateUser($_POST["userId"], $_POST["session"]);

// Valid session

$qry = $db->prepare('SELECT n.id, n.type, n.time, n.isRead, n.postId, n.commentId, n.text, n.inReplyToCommentId, u.id as byUserId, 
    ( SELECT COUNT(nu.id)
    FROM notificationUsers AS nu
    WHERE nu.notificationId = n.id ) as detail1,
    ( SELECT nu2.userId
    FROM notificationUsers AS nu2
    WHERE nu2.notificationId = n.id ORDER BY nu2.id DESC LIMIT 1 ) as latestUserId FROM notifications AS n LEFT JOIN userData AS u ON n.byUserId = u.id
    WHERE n.userId = :userId ORDER BY n.time DESC');
$qry->bindParam(':userId', $_USERDATA["userId"], PDO::PARAM_INT);
$qry->execute();

$notificationsArray = $qry->fetchAll(PDO::FETCH_ASSOC);


$returnValue = array();
$returnValue["status"] = "1";
$returnValue["title"] = "Success";
$returnValue["message"] = "Downloaded notifications";
$returnValue["data_notifications"] = $notificationsArray;
exit(json_encode($returnValue));



?>

...

ОБНОВЛЕНИЕ 1

Поэтому я решил сделать следующее:

Поместить каждый не общий файл в папку примерно так: 

/api/v1.0/file.php

Но каждый ресурс, например (изображения), находится за пределамиAPI 

/resources/images/profilepictures/image.jpg

Если я сделаю небольшое изменение, я просто обновлю файлы в папке api/v1.0/.

Затем все пользователи, использующие Application v1.1 они запрашивают myapp.com/api/v1.1/, но я перенаправляю их в api / v1.0 /, где я могу предоставить пользователям правильные данные (в зависимости от того, был ли запрос от v1.0 или v1.1)

Если версии складываются, и я выпускаю большее обновление, я создам новую папку с именем v2.0, и так оно и будет ...

Или как вы думаете?Как мне это сделать?

Ответы [ 3 ]

4 голосов
/ 31 мая 2019

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

Если вы используете фреймворк, такой как Laravel или Symfony, вы можете сохранять общий каталог моделей и помощников при создании каталога Controllers.версия с подкаталогом, таким как v1.x, v2.x и т. д.

Это может сделать вашу жизнь проще, если вы используете механизм маршрутизации, поэтому, скажем, например, ваш v1.0 имеет 50 конечных точек API, и вы 'вы планируете модифицировать 5 из них для v1.2 без обратной совместимости, в этом случае все остальные из 45 конечных точек API будут по-прежнему идентичны v1.0, и вы не хотите дублировать их в каталоге v1.2,

<?php

$versions = ["v1.0", "v1.2"];

route("/api/v1.0/foobar", "Controllers/v1.0/FoobarController@doSomething");
route("/api/v1.0/footar", "Controllers/v1.0/FoobarController@doTar");

route("/api/v1.2/foobar", "Controllers/v1.2/FoobarController@doSomething");

function route($endpoint, $controller)
{
    // Logic to call function of a respective class/file 
    // and call previous version of an API if function/endpoint is not redefined in current version
}
?>

Поэтому в приведенном выше случае, когда клиент вызывает /api/v1.2/footar, он должен выполнить /api/v1.0/footar для потребителя API.

Надеюсь, это поможет.

1 голос
/ 06 июня 2019

Многие другие ответы рекомендуют использовать фреймворки (Symfony и т. Д.), Которые имеют свои преимущества (больше plug-and-play) и недостатки (у них есть много шаблонов для настройки ). Я сосредоточусь на чистом нативном решении PHP для этой проблемы со следующими целями:

1. Сохраняйте базу кода как можно меньше (очень мало повторений)
2. Поддержка самых простых реализаций (главное преимущество перед каркасными решениями, поскольку меньше шаблонов)

Это будет пример реализации решения. index.php (первый файл): 

<?php
require_once("path/to/config");
require_once("path/to/helpers/that/are/used/by/both/apis");

//This is where we decide where to route the request
if(strpos('/v1/', $_SERVER["REQUEST_URI"]) {
    //This is api v1 so use api v1
    require_once("path/to/api/objects/1.0");
} else {
    //This is api v2 (or the default since most recent)
    require_once("path/to/api/objects/2.0");
}
//Use the classes just imported to handle the request:
$apiObject = new Responder(); //Imported from one of the two api versions
echo $apiObject->handle(); 

?>

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

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

Это более элегантное решение для действительно простых и еще более сложных серверных служб PHP.

1 голос
/ 31 мая 2019

Как я вижу, вы хотите написать свои API на простом PHP без каких-либо фреймворков. Я просто хочу привести вас к правильному пути и дать вам некоторое представление о начале серверной разработки в PHP.

  • Сначала выберите фреймворк для кодирования. Может быть CodeIgniter , это простой в использовании [Читать далее]
  • Изучите MVC шаблон проектирования, который поддерживает большинство фреймворков, и он облегчит вашу жизнь, если вы хотите сохранить или расширить существующий код - это необходимо и достаточно просто, не напуган
  • Клонирование всего проекта для обратной совместимости является излишним (предположим, что вы хотите просто исправить ошибку в слое доступа к базе данных (модель / репозиторий), вы должны повторить ее для всех других версий) - вы можете добиться этого, клонируя только контроллеры и определение новых маршрутов - [Тем не менее, у вас есть предыдущая проблема в бизнес-логике на уровне контроллера из-за шаблона проектирования]
  • Если вы хотите более сильный подход, вы должны начать кодировать с Шаблон репозитория с сервисным уровнем (он же MVCS) и использовать желаемую платформу, возможно, Laravel для предотвращения связывания кода в различных версиях уровня контроллера и сохранения общего доступа. Бизнес-логика на уровне сервиса (отделить его от контроллера)
  • Документируйте важные вещи в коде с помощью тегов комментариев документации, таких как @deprecated и @since, чтобы указать, когда некоторые функциональные возможности устарели или добавлены (поскольку вы не можете очистить устаревшие функциональные возможности, пока соответствующая версия не будет удалена). [Check эта ссылка чтобы получить идею]
  • Исследование о стандартах версий - SEMVER
  • Не кодировать на простом PHP
...