Jak dodać niestandardowe punkty końcowe do API WordPress?

Ostatnio pracowałem nad projektem, w którym chcieliśmy wykorzystać AngularJS na frontendzie i WordPress jako backend. W celu wymiany danych pomiędzy AngularJS a WordPress wykorzystaliśmy WordPress REST API. Praca z REST API w WordPressie była dobrym doświadczeniem. WordPress zapewnia bardzo czysty i wydajny sposób na rozpoczęcie korzystania z interfejsu API REST. Ten popularny CMS pozwala również na zbudowanie niestandardowego punktu końcowego do wysyłania/odbierania danych za jego pośrednictwem.

W tym artykule dowiemy się, jak utworzyć niestandardowy punkt końcowy w WordPress REST API. Zamierzam zbudować niestandardowy punkt końcowy dla żądania GET i POST.

Korzystanie z WordPress REST API

Wszyscy wiedzą o popularności aplikacji mobilnych i frameworków JavaScript. Budując aplikację mobilną lub stronę internetową z wykorzystaniem frameworka JavaScript musisz wejść w interakcję z backendem w celu wymiany danych.

Do celów backendowych można wybrać dowolną platformę, taką jak WordPress, Laravel. Jedynym wymaganiem jest posiadanie punktów końcowych API na platformie backendowej do wymiany danych z frontendem. System frontendowy daje wywołanie API do backendu. Na backendzie powinniśmy zbudować system, który będzie odbierał żądania API i je przetwarzał.

Najczęściej używaliśmy dwóch typów żądań w punktach końcowych API – GET i POST. Podczas gdy wywołujemy API z żądaniem GET, API w odpowiedzi poda dane z bazy danych lub usunie dane w bazie danych. W przypadku żądań POST albo wstawiamy rekordy do bazy danych, albo porównujemy dane z bazą danych. Oczywiście nie jest to zasada kciuka. Użytkownicy mogą decydować, jak się zachowuje, w zależności od ich wymagań.

Autoryzacja przy użyciu WordPress REST API

WordPress REST API wymaga śledzenia przepływu Basic Auth. W Basic Auth musisz wysłać token w nagłówku Authorization podczas wysyłania żądania API. Począwszy od WordPress 5.6, w systemie pojawia się nowa funkcja „Hasła aplikacji". To hasło aplikacji (z nazwą użytkownika) może być używane jako token w nagłówku Authorization.

Hasła aplikacji są dostępne dla wszystkich użytkowników w witrynach obsługiwanych przez SSL/HTTPS. Jeśli z jakiegoś powodu nie korzystasz z SSL na swojej stronie, udostępniasz go za pomocą poniższego filtra.

add_filter( 'wp_is_application_passwords_available', '__return_true' );

Opcję Hasła aplikacji znajdziesz na stronie Użytkownicy->Profil. Wygeneruj hasło, po prostu wprowadzając nazwę aplikacji.

Na zrzucie ekranu zauważysz spacje w haśle. Hasła aplikacji mogą być używane z lub bez spacji. Jeśli zostaną uwzględnione, spacje zostaną po prostu usunięte, zanim hasło zostanie zaszyfrowane i zweryfikowane po stronie WordPress.

Teraz jesteś gotowy z hasłem. Następnie, aby utworzyć token Auth, musisz utworzyć zakodowaną Base64 wersję swojej nazwy użytkownika i hasła aplikacji. Załóżmy, że twoja nazwa użytkownika to „admin”, a hasło to „Ho9c 9vGs AOBG nXb0 FPpr W5vO”. Użyj poniższej instrukcji, która daje ostateczny ważny token.

<?php
$username = 'admin';
$application_password = 'Ho9c 9vGs AOBG nXb0 FPpr W5vO';
 
echo base64_encode($username.':'.$application_password);

Powyższa instrukcja zwraca wartość tokena jako YWRtaW46SG85YyA5dkdzIEFPQkcgblhiMCBGUHByIFc1dk8=. Ten token musisz wysłać w nagłówku Authorization podczas wywoływania WordPress REST API.

Zaloguj się za pomocą WordPress REST API

Jesteśmy gotowi z wartością tokena Basic Auth. Teraz zbudujmy niestandardowy punkt końcowy dla systemu logowania. W poniższym kodzie piszemy punkt końcowy API, który otrzymuje dane uwierzytelniające użytkownika i sprawdza, czy dane są poprawne, czy nie. Musisz dodać ten kod w swoim functions.phppliku motywów .

add_action(
    'rest_api_init',
    function() {
        register_rest_route(
            'api',
            'login',
            array(
                'methods'  => 'POST',
                'callback' => 'login',
            )
        );
    }
);

WordPress udostępnia akcję „rest_api_init”, za pomocą której możemy zbudować nasze niestandardowe punkty końcowe. Tutaj używam funkcji register_rest_route, która produkuje powyższy punkt końcowy API jako YOUR_SITE_URL/wp-json/api/login.

W naszym kodzie „api” to przestrzeń nazw, „login” to trasa, metoda to „POST”, a funkcja zwrotna to „login”. Metoda wywołania zwrotnego będzie miała rzeczywistą logikę.

Aby napisać logikę przepływu logowania, wymagane parametry POST to e-mail i hasło, które należy przesłać z frontendu wraz z nagłówkiem Authorization. Publikując te dane, musisz przesłać je w formacie JSON. Na przykład z VSCode za pomocą Rest Client Extension wysyłam żądanie POST, jak pokazano na zrzucie ekranu poniżej.

Tutaj przekazaliśmy token utworzony w poprzednim kroku jako wartość nagłówka Authorization.

Dodaj poniższy kod dla login()metody w functions.phppliku.

function login( WP_REST_Request $request) {
    $arr_request = json_decode( $request->get_body() );
 
    if (! empty( $arr_request->email) &&! empty( $arr_request->password)) {
        // this returns the user ID and other info from the user name.
        $user = get_user_by( 'email', $arr_request->email );
 
        if (! $user) {
            // if the user name doesn't exist.
            return [
                'status' => 'error',
                'message' => 'Wrong email address.',
            ];
        }
 
        // check the user's login with their password.
        if (! wp_check_password( $arr_request->password, $user->user_pass, $user->ID)) {
            // if the password is incorrect for the specified user.
            return [
                'status' => 'error',
                'message' => 'Wrong password.',
            ];
        }
 
        return [
            'status' => 'success',
            'message' => 'User credentials are correct.',
        ];
    } else {
        return [
            'status' => 'error',
            'message' => 'Email and password are required.',
        ];
    }
}

Uwaga: jeśli otrzymasz błąd typu „Nie znaleziono trasy pasującej do adresu URL i metody żądania”, musisz zaktualizować swój link bezpośredni.

Po otrzymaniu wartości „success” dla klucza „status” możesz zalogować użytkownika w aplikacji frontendowej.

Zbuduj punkt końcowy dla żądania GET

Widzieliśmy, jak budować niestandardowe punkty końcowe dla żądań POST. Teraz przyjrzyjmy się żądaniu GET za pomocą WordPress REST API. W tym celu napiszę API, które usuwa użytkownika. Z interfejsu użytkownika należy przekazać identyfikator użytkownika jako parametr GET.

add_action(
    'rest_api_init',
    function() {
        register_rest_route(
            'api',
            'delete_user/(?P<id>d+)',
            array(
                'methods'  => 'GET',
                'callback' => 'delete_user',
            )
        );
    }
);

Ten kod generuje punkt końcowy interfejsu API jako YOUR_SITE_URL/wp-json/api/delete_user/id. Do tego punktu końcowego zamiast id należy przekazać rzeczywisty identyfikator użytkownika.

Metoda wywołania zwrotnego delete_userbędzie miała następujący kod.

function delete_user( $data) {
    // delete the user
    require_once(ABSPATH.'wp-admin/includes/user.php' );
    if (wp_delete_user($data['id'])) {
        return [
            'status' => 'success',
            'message' => 'User deleted successfully.',
        ];
    }
 
    return [
        'status' => 'error',
        'message' => 'It seems you passed the wrong user id.',
    ];
}

Mam nadzieję, że rozumiesz, jak zbudować niestandardowy punkt końcowy w WordPress REST API. Podziel się swoimi przemyśleniami i sugestiami w sekcji komentarzy poniżej.

Powiązane artykuły

• Szybki przewodnik po WooCommerce REST API
• Jak wyświetlić powiązane produkty za pomocą WooCommerce REST API
• Zamiana mowy na tekst przy użyciu transkrypcji Amazon w PHP