Klient konsekwentnie wysyła żądania z nagłówkiem accept „application / json” i typem treści „application / json”
Tak, jest to właściwe postępowanie, ale nie oznacza, że sprzedawca się tym przejmuje. Chociaż całkowicie rozumiem twoją frustrację, ponieważ uważam również, że usługa JSON powinna zawsze dawać odpowiedź JSON, ale istnieje wiele przykładów, w których tak nie jest.
W całym projekcie ta sama praktyka została zastosowana u dwóch różnych dostawców i dwóch różnych usług. Musiałem uzasadnić, dlaczego usługi musiały zostać zmienione. Dostawcy stwierdzili, że klient powinien sobie z tym poradzić i nawet moja wybrana biblioteka REST została zakwestionowana (RestEasy), ponieważ domyślnie nie radzi sobie z tym „od razu”.
Cóż, muszę się zgodzić ze sprzedawcą. To ich usługa i tak długo, jak wyraźnie dokumentują specjalne przypadki korzystania z niej, tak naprawdę nie można narzucić, że to zmieniają. Jest to dla nich wada, ponieważ programiści będą powoli przyjmować swój interfejs API, a jeśli posłuchają tego, czego potrzebują programiści, to zmienią go, ale niestety nie ma zasady, że muszą przestrzegać standardów.
Pytanie, czy coś mi umknęło?
Nagłówki żądań nic nie znaczą, chyba że zostaną poprawnie przerwane na drugim końcu. Wiem, że jeśli opracuję internetowy interfejs API za pomocą PHP, to do diabła z nagłówkami żądań. Mogę odpowiadać na wszystko, co chcę. Natomiast usługa skonfigurowana w IIS z C # oferuje znacznie łatwiejszą obsługę nagłówków żądań, ich typu i obsługę typu odpowiedzi. Ma to wiele wspólnego z narzędziami, których dostawca użył do zbudowania API.
Jestem pedantyczny w tej sprawie?
Tak i nie. Mam znajomych programistów, którzy nie byliby w stanie przejść dalej. Zostałyby tak naprawione przez problem i nie byłyby w stanie wykonywać innych zadań, dopóki interfejs API nie będzie działał w oczekiwany sposób. To jest pedantyczne.
Jest to problem, ponieważ dostawca stworzył „więcej pracy” w celu wykonania twoich zadań. Sfrustrowałoby to każdego. Wiem, że byłbym.
Czy jest OK mieć interfejs API JSON, który nie zawiera treści typu application / json w tym scenariuszu?
Oczywiście, ale to nie jest dobra praktyka.
Klient może tylko powiedzieć serwerowi, jaki jest typ kontekstowy request. Nie ma możliwości narzucenia typu zawartości dla response. Klient może jedynie poinformować serwer, że będzie acceptkolekcją możliwych typów zawartości.
Definicje pól nagłówka
Pole Akceptuj nagłówek żądania może służyć do określania określonych typów nośników, które są akceptowane w odpowiedzi. Za pomocą nagłówków Accept można wskazać, że żądanie jest ograniczone do niewielkiego zestawu pożądanych typów, tak jak w przypadku żądania obrazu w linii.
Klient może zażądać obrazu image/jpeg, ale serwer odpowiada text/htmli kodem stanu, 404jeśli obraz nie został znaleziony. Serwery mogą również reagować niepoprawnie. Istnieje wiele witryn Wordpress, które odpowiadają text/htmlkodem stanu i nie wyszukują 200plików stron.
To wszystko jest ZŁA praktyka ze strony serwera. Próbuję ci powiedzieć, że jest to absolutnie możliwe i zdarza się często. Ludzie nie wiedzą, co robią, kiedy konfigurują te rzeczy.
Referencje będą mile widziane. Jak rozwiązać tę sytuację z komercyjnego punktu widzenia?
Wystąpił ten problem w kilku projektach. Dostajesz postdane JSON do serwera, a ono zwraca odpowiedź JSON lub HTML.
Naprawdę nie jest wielkim problemem wiedzieć, który typ był w odpowiedzi. Jeśli pierwszym znakiem jest {lub [możesz założyć JSON. Jeśli tak, <możesz założyć HTML. Tak sobie z tym poradziłem w przeszłości. Czasami programista, który napisał API, wie wszystko o nagłówkach HTTP. Wszystko powraca jako text/htmlodpowiedzi. Jeśli masz szczęście, mają Apache skonfigurowane domyślnie, text/plainco może czasem pomóc.
Te problemy istnieją i będą istnieć w dalekiej przyszłości. Komunikacja między serwerami to zdecydowanie nieuregulowane działanie. Nie ma organu zarządzającego, który wyrzuciłby sprzedawcę ze związku dla serwera, który udziela złych odpowiedzi HTTP.