Czy powinienem zezwolić na nieznane parametry?

12

Projektuję interfejs API RESTful i napotkałem problem z tytułem, dla zachowania przejrzystości:

Czy powinienem szybko zawieść, jeśli klient wyśle ​​nierozpoznany parametr? Na przykład,

http://example.com/api/foo?bar=true&paula=bean

Powyżej barjest poprawnym parametrem, ale paulanie jest określony przez API. Czy powinienem

  • Ostrzeż klienta o błędzie
  • Szybko zawieść
  • Zignoruj ​​to

Jeśli ostrzeżę klienta, mogę wydać ostrzeżenie tylko dla pierwszego parametru, ponieważ może on wysyłać ich prawie nieskończoną liczbę, a serwer prawdopodobnie ma lepsze rzeczy do zrobienia. Podobnie w przypadku niepowodzenia określa tylko pierwszy nieprawidłowy parametr jako problem.

Wolę niepowodzenie niż ostrzeżenie, aby zmusić programistę do podjęcia działania, ponieważ w przeciwnym razie mogą zignorować problem i nadal marnować zasoby lub skończyć nieumyślnie kultywowaniem ładunków. W tym względzie nic gorszego nie robić.

Czy moje argumenty mają sens? Czy istnieje akceptowana praktyka w takich sprawach?

rath
źródło
Na podstawie małego testu wszystkie testowane witryny po prostu ignorują nieznane parametry, które im podałem.
Bart van Ingen Schenau
@BartvanIngenSchenau Same tutaj. Jest w porządku dla stron internetowych, ale nie sądzę, że jest w porządku dla rzeczywistego API
rath
2
Problemem jest kompatybilność w przód. Jeśli nieznane argumenty zostaną zignorowane, możliwe jest użycie ich w przyszłych wersjach w taki sposób, że klienci mogą programować się do nowego API i nadal uzyskać rozsądne zachowanie na starych serwerach.
walpen
@walpen To interesujący punkt. Zajmie się tym używanie wersjonowanych adresów URL api/v1itp., Ale nadal nie pozwala na aktualizacje przyrostowe. +1
Rath
Tam możesz znaleźć plusy i minusy z prawdziwej perspektywy na żywo: ścisłe parametry i twój interfejs API .
Remek Ambroziak

Odpowiedzi:

12

Moim zdaniem powinieneś zwrócić stan Nieprawidłowe żądanie, aby klient wiedział, że to, co próbuje zrobić, jest nieprawidłowe. Na moją opinię w tej sprawie wpływa koncepcja, że ​​interfejsy API RESTful są wykrywalne . Jeśli podajesz wystarczające informacje z góry, klient nigdy nie próbuje złożyć nieprawidłowego żądania na początek. Jeśli tak się stanie, oznacza to, że coś jest nie tak w kodzie klienta, a niepowodzenie szybko powiadomi sekundę o tym błędzie. Oczywiście jest to bardzo purystyczne podejście i może nie być zalecane, jeśli nie można wykryć interfejsu API.

Bardziej pragmatycznym podejściem może być zignorowanie niepoprawnych parametrów, ale tak czy inaczej, należy dobrze udokumentować zachowanie.

Gumowa kaczuszka
źródło
1
Jako rozszerzenie: jeśli klient wyśle ​​jakieś nieznane / tylko do odczytu / nieaktualne parametry, oznacza to, że klient oczekuje pewnych zachowań, które nie zostaną spełnione. Dlatego wykonywanie jakiejkolwiek akcji jest niebezpieczne. Zgadzam się więc, zła prośba
Stepan Stepanov
Dzięki @StepanStepanov, ale istnieje filozofia „Bądź liberalny w tym, co akceptujesz, wyraźnie mówiąc o tym, co wysyłasz”, leżąca u podstaw większości architektury sieci. Mając to na uwadze, mógłbym z łatwością napisać odpowiedź w przeciwieństwie do tej, którą już napisałem.
RubberDuck,
3
Przejrzałem to)). A strona o prawie Postela mówi również, że „kod, który otrzymuje dane wejściowe, powinien akceptować dane niezgodne, o ile ich znaczenie jest jasne”. Myślę, że jeśli klient wyśle ​​nam jakiś nieznany parametr, jego znaczenie nie może być jasne. Jeśli klient wyśle ​​nam przestarzały parametr, jest jasne, że nie będzie działać tak jak wcześniej i zgodnie z oczekiwaniami klienta. Jeśli klient wyśle ​​nam parametr tylko do odczytu, jest jasne, że nie zostanie zapisany, jak chce klient.
Stepan Stepanov
0

Jeśli korzystasz z publicznego interfejsu API (lub interfejsu API, który będzie używany przez inny zespół), zaleciłbym zwrócenie błędu zgodnie z sugestią @RubberDuck.

Jeśli Twój interfejs API zostanie zużyty tylko w zespole (lub tylko przez ciebie), może być łatwiej zignorować dodatkowe pola (np. Wymaga mniej kodu i łatwiej zrobić).

Konstantin Petrukhnov
źródło