ОДМОР

Репрезентативни државни пренос

РЕСТ је акроним за Репрезентативни државни пренос.

Шта је Репрезентативни државни пренос?

Архитектонски стил за пројектовање умрежених апликација. У готово свим случајевима, ослања се на комуникациони протокол без држављанства, клијент-сервер, кеширајући комуникациони протокол, ХТТП протокола. Идеја иза РЕСТ-а је да се сви ресурси на страни сервера третирају као објекти који се могу креирати, читати, ажурирати или брисати кроз скуп дефинисаних операција. Овај концепт је уско усклађен са стандардним операцијама које подржава ХТТП: ПОСТ, ГЕТ, ПУТ и ДЕЛЕТЕ.

Зашто се то зове представнички државни трансфер

Термин Репрезентативни државни пренос је изабран из специфичних разлога:

  • Репрезентативни односи се на репрезентације ресурса (документ или објекат који сте захтевали од сервера) пренете преко мреже. Клијент може лако да рукује овим приказима у форматима као што су КСМЛ, ЈСОН, Или Иамл.
  • Државни трансфер подразумева да свака интеракција клијента и сервера преноси стање. Када клијент затражи ресурс, одговор сервера је у суштини пренос стања тог ресурса на клијента. Овај пренос стања омогућава РЕСТфул апликацији да буде без стања, што значи да сваки захтев од клијента ка серверу мора да садржи све информације потребне за разумевање и довршавање захтева. Сервер не чува никакво стање о сесији клијента на страни сервера.

Принципи ОДМОРА

РЕСТ је изграђен на неколико кључних принципа који дефинишу његову једноставност и моћ:

  1. без држављанства: Сваки захтев од клијента до сервера мора да садржи све информације неопходне за разумевање и довршавање захтева. Сервер нема стање сесије; држи се у потпуности на страни клијента.
  2. клијент-сервер: Јединствени интерфејс одваја клијенте од сервера. Ово раздвајање брига подржава независну еволуцију логике на страни клијента и складиштења података на страни сервера, побољшавајући преносивост клијентског интерфејса на више платформи.
  3. Кеширање: Одговори се морају дефинисати као кеширани или не да би спречили клијенте да поново користе застареле или неприкладне податке као одговор на даље захтеве.
  4. Слојевити систем: Клијент обично не може да каже да ли је повезан директно на крајњи сервер или на посредника. Посреднички сервери могу побољшати скалабилност система омогућавањем балансирања оптерећења и обезбеђивањем дељених кеша.
  5. Јединствени интерфејс: Да би оствариле предности РЕСТ-а, апликације морају да се придржавају јединственог интерфејса. Ово обично укључује коришћење стандардних ХТТП метода на доследан начин и праћење УРЛ-ова оријентисаних на ресурсе.

ПХП Пример

Креирање РЕСТфул АПИ-ја у ПХП-у укључује руковање ХТТП захтевима (ГЕТ, ПОСТ, ПУТ, ДЕЛЕТЕ) и одговарање са подацима у формату као што је ЈСОН или КСМЛ. Ево поједностављеног примера РЕСТфул АПИ-ја у ПХП-у који управља листом задатака. Овај пример демонстрира руковање ГЕТ и ПОСТ захтевима ради једноставности.

ово PHP пример ће вам показати како да креирате две крајње тачке: једну за преузимање листе задатака (GET /tasks) и још један за додавање новог задатка (POST /tasks).

index.php – Улазна тачка

<?php
// Define a simple array of tasks as our "database"
$tasks = [
    ['id' => 1, 'title' => 'Buy groceries', 'completed' => false],
    ['id' => 2, 'title' => 'Finish homework', 'completed' => false]
];

// Get the request method
$requestMethod = $_SERVER['REQUEST_METHOD'];

// Simple router
switch ($requestMethod) {
    case 'GET':
        getTasks();
        break;
    case 'POST':
        addTask();
        break;
    default:
        // Handle other HTTP methods or return an error
        header('HTTP/1.1 405 Method Not Allowed');
        break;
}

function getTasks() {
    global $tasks;
    header('Content-Type: application/json');
    echo json_encode($tasks);
}

function addTask() {
    global $tasks;
    $input = json_decode(file_get_contents('php://input'), true);
    if (!isset($input['title']) || !isset($input['completed'])) {
        header('HTTP/1.1 400 Bad Request');
        echo json_encode(['message' => 'Missing title or completed status']);
        return;
    }

    $newTask = [
        'id' => end($tasks)['id'] + 1,
        'title' => $input['title'],
        'completed' => $input['completed']
    ];

    $tasks[] = $newTask;
    header('Content-Type: application/json');
    echo json_encode($newTask);
}

?>

Како све функционише

  • Ова скрипта делује као једноставна АПИ крајња тачка. У зависности од методе ХТТП захтева, он или враћа листу задатака (GET) или додаје нови задатак на листу (POST).
  • за GET захтева, једноставно исписује $tasks низ у ЈСОН формату.
  • за POST захтева, чита ЈСОН корисни терет из тела захтева (претпоставља се да садржи title completed статус), додаје нови задатак у $tasks низ и враћа нови задатак као ЈСОН.
  • Овај пример користи ПХП глобални низ као лажну базу података. У апликацији из стварног света, вероватно бисте ступили у интеракцију са базом података за складиштење и преузимање задатака.

Тестирање АПИ-ја

Можете тестирати овај АПИ користећи алате као што су Постман или цУРЛ. На пример, да бисте додали нови задатак:

curl -X POST -H "Content-Type: application/json" -d '{"title":"Learn REST","completed":false}' http://localhost/index.php

И да добијете листу задатака:

curl -X GET http://localhost/index.php

Ово је веома основни пример који треба да илуструје концепт РЕСТфул АПИ-ја у ПХП-у. Сценарији из стварног света би захтевали робусније руковање захтевима, управљање грешкама и безбедносна разматрања као што су аутентификација и валидација уноса.

  • Скраћеница: ОДМОР
Назад на врх дугмета
близу

Адблоцк откривен

Martech Zone је у могућности да вам пружи овај садржај без икаквих трошкова јер ми монетизујемо наш сајт путем прихода од огласа, партнерских веза и спонзорстава. Били бисмо захвални ако бисте уклонили свој блокатор огласа док гледате наш сајт.