Wtyczki do przeglądarek typu REST client zwracają 404

pytanie zadane 17 stycznia 2018 w PHP przez User007 Bywalec (2,400 p.)

Witam.

Zaczynam naukę tworzenie REST api w php i na początek chciałem aby przeglądarka zwróciła mi tylko rodzaj zapytania.

Cały mój plik index.php składa się tylko z jednej linijki: echo $_SERVER["REQUEST_METHOD"]

Według poradników youtubowych zainstalowałem sobie do firefoxa plugin "RESTClient" a do chroma "RESTeasy", ale w obu przypadkach do zapytań innych niż GET dostaje "404 nie znaleziono."

Dlaczego nie zwraca mi innego typu requestu?

Używam XAMPP o ile to istotne.

komentarz 17 stycznia 2018 przez ShiroUmizake Nałogowiec (46,300 p.)

Zainstalowałeś potrzebne oprgramowanie do REST? Nie wiem jak to jest PHP, ale do JAVY potrzebne jest specjalne opgramowanie.

1 odpowiedź

odpowiedź 17 stycznia 2018 przez Ehlert Ekspert (212,670 p.)

To zainstaluj Postmana.

komentarz 17 stycznia 2018 przez CzikaCarry Szeryf (75,340 p.)

Albo po prostu zacznij pisać unit testy dla REST API (zagaduję że chcesz protestować te API) :)

komentarz 17 stycznia 2018 przez Ehlert Ekspert (212,670 p.)

Cały mój plik index.php składa się tylko z jednej linijki: echo $_SERVER["REQUEST_METHOD"]

zacznij pisać unit testy

Komuś się tu na żarty zebrało

Btw testy api to nie unit testy.

komentarz 17 stycznia 2018 przez CzikaCarry Szeryf (75,340 p.)

Myślę, że w tym kontekście to jednak unit testy: https://www.360logica.com/blog/api-testing-vs-unit-testing-whats-the-difference/

Poza tym testów nigdy za mało, sam niedawno zacząłem testować i teraz cały czas Red Green Refactor :)

komentarz 17 stycznia 2018 przez Ehlert Ekspert (212,670 p.)

Another key difference between API and unit testing lies in the test case design. Unit tests are typically designed by the developers to verify the functionality of each unit. The scope of unit testing often does not consider the system-level interactions of the various units; the developers simply verify that each unit in isolation performs as it should.

API testing, like other activities owned by the QA team, must consider the ‘full’ functionality of the system, as it will be used by the end user (in this case, another program). This means that API tests must be far more extensive than unit tests, and take into consideration the sorts of ‘scenarios’ that the API will be used for, which typically involve interactions between several different modules within the application.

Przeczytałeś artykuł do którego dałeś linka?

komentarz 17 stycznia 2018 przez CzikaCarry Szeryf (75,340 p.)

Tak, przeczytałem:

In many organizations we’ve worked with, the unit testing and API testing activities are owned by different teams. Unit testing is almost always an activity that is owned by the development team; developers are expected to build unit tests for each of their code modules (these are typically classes, functions, stored procedures, or some other ‘atomic’ unit of code), and to ensure that each module passes its unit tests before the code is included in a build. This practice makes a lot of sense because it helps the developers solidify their code. Often times, this effort requires debugging and bug-fixing in real-time.

API testing, on the other hand, is typically an activity owned by the QA team, a staff other than the author of the code. API tests are often run after the build has been created, and it is common that the authors of the tests do not have access to the source code; they are essentially creating black box tests against an API rather than the traditional GUI.

komentarz 17 stycznia 2018 przez User007 Bywalec (2,400 p.)

@Ehlert,
Ok zainstaluje tego postmana.

komentarz 17 stycznia 2018 przez Ehlert Ekspert (212,670 p.)

@User007 zainstaluj go jako program a nie rozszerzenie przeglądarki. Nie jest ono już wspierane.

@CzikaCarry na prawdę tak ciężko rozróżnić unit test, który testuje najmniejszą jednostkę logiczną kodu, od testu api, które testuje funkcjonalność całego api? No chyba że Twoje api zwraca hello World.

komentarz 18 stycznia 2018 przez User007 Bywalec (2,400 p.)

Zainstalowałem jako program i progres jest taki że teraz zwraca mi poprawnie odpowiedź dla GET i POST. Dla jakiegokolwiek innego requesta dalej mam 404.

Czy coś pominąłem, czy może czegoś nie zrozumiałem, odnośnie zapytań innych niż GET i POST?

komentarz 18 stycznia 2018 przez Ehlert Ekspert (212,670 p.)

To zrob var_dumpa.

komentarz 18 stycznia 2018 przez User007 Bywalec (2,400 p.)
edycja 18 stycznia 2018 przez User007

Zrobiłem też, i dalej wynikiem zapytania jest:

<!doctype html><title>404 Not Found</title><h1 style="text-align: center">404 Not Found</h1><hr/><p style="text-align: center">PhpStorm 2016.3.2</p>

Wrzuciłem też plik na serwer i tam dla zapytań innych niż GET i POST otrzymuję:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
    <head>
        <title>403 Forbidden</title>
    </head>
    <body>
        <h1>Forbidden</h1>
        <p>You don't have permission to access /
on this server.
            <br />
        </p>
        <p>Additionally, a 403 Forbidden
error was encountered while trying to use an ErrorDocument to handle the request.</p>
    </body>
</html>

komentarz 18 stycznia 2018 przez User007 Bywalec (2,400 p.)

Dobra już się częściowo wyjaśniło.

Na serwerze nie były te polecenia włączone, musiałem dopiero zgłosić prośbę o uruchomienie.

A co do serwera lokalnego to dopiero gdy utworzyłem w pliku httpd-vhost wirtualnego hosta i dokonałem przekierowania to requesty zaczęły działać.

Na samym adresie localhost:63342 lub innym porcie nie działało. Nie wiem dlaczego.

Ktoś ma jakiś pomysł?