Jakie są niektóre z pułapek/wskazówek, które można podać przy opracowywaniu usługi sieciowej?

Question

Szukam opracowania usługi internetowej (API) w PHP, aby zaoferować klientom łatwiejszy sposób integracji z naszą platformą. Istnieją wywołania workflow, które będą sprawdzane za pomocą user/pass, a także niektóre opcje raportowania.

Niestety nie mogę podać więcej szczegółów ani kodu na ten temat, a ja nigdy nie opracowałem usługi internetowej, ale mam doświadczenie w korzystaniu z nich za pośrednictwem protokołu SOAP.

Teraz również powinienem zaoferować stan lub status przepływu pracy i myślę, że REST byłby najlepszym wyborem, ale wciąż szukał opinii na ten temat.

Do celów sprawozdawczości Chciałbym zaproponować różne opcje, takie jak XML, Excel/CSV, z dowolnego powodu, który bym wybrał jeden nad drugim?

Jakie są niektóre pułapki, na które powinienem zwrócić uwagę?

Co to są niektóre klejnoty, które ktoś może zaoferować.

Z góry dziękuję za pomoc, ponieważ jest to dla mnie bardzo ważne.

Aktualizacja # 1:

• Jaki byłby najbardziej bezpieczna metoda?
• Co jest najbardziej elastyczny sposób (Platform Independent)

Aktualizacja # 2: trochę o przepływie danych. Każdy użytkownik ma uprawnienia do korzystania z interfejsu API i żadne dane nie są współużytkowane przez użytkowników. Użycie jest wysyłane, żądanie przetwarzane i zwracany. brak aktualizacji. (Think Google) wysłano żądanie wyszukiwania i wyniki są podane, ale w moim przypadku podano tylko jeden wynik. Nie wiem, czy jest to potrzebne, więc to FYI.

Answer 1

Always handle errors and exceptions. 

Problemy zawsze sprawiają, że ich obecność jest odczuwana w aplikacji/api. Albo na początku, albo poprzez dalszy rozwój. Nie pozostawiaj tego jako zadania końcowego i wyjaśnij, kiedy wystąpi błąd, z dobrze udokumentowanymi komunikatami odpowiedzi.

Również jeśli Twoja usługa obsłuży wiele żądań, a dla tego samego identyfikatora zasobu (niezależnego od użytkownika) ten sam zasób zostanie zwrócony, pamiętaj o buforowaniu tych informacji. I to nie tylko ze względów związanych z wydajnością, ale także z przypadkami, w których pojawiały się błędy. W ten sposób możesz przynajmniej podać coś klientowi (być może użyteczne, więcej kontekstu wymaga jawności).

Answer 2

Największą i najważniejszą pozycją, którą mogę zaoferować, to zagwarantować, że twoja infrastruktura za WS lub przynajmniej to, co podajesz za pośrednictwem WS, jest bezpaństwowcem. W momencie, gdy odejdziesz od tego, stanie się koszmarem i zaczniesz musieć kłaść kod, aby chronić twoje dane przed złym pomysłem.

Przykładem może być dwóch klientów dokonujących zmian danych za pośrednictwem WS, tzn. ... zapisanie konfiguracji. To, jak sobie z tym poradzisz, sprawia, że ​​rzeczy są interesujące. Jeśli twoje dane wychodzą tylko na zewnątrz, jesteś w znacznie lepszej sytuacji, jeśli musisz poprzeć dane do tyłu.

Należy również dokładnie zapoznać się z interfejsem API, podobnie jak z każdym interfejsem API. W momencie, gdy masz wersję na wolności, a następnie zdecydujesz, że potrzeby API zostały zmienione lub przestarzałe, zaczynają powodować problemy dla bazy klientów korzystających z twojego WS.

Answer 3

Obecnie pracuję nad aplikacją internetową, która zawiera usługę sieciową (lub 2 w ASP.NET MVC) i bardzo polecam spojrzenie na zasady związane z architekturą zorientowaną na usługi (SOA), ponieważ odkryłem, że najbardziej Ważnym aspektem jest poprawne zaprojektowanie interfejsu API serwisu internetowego, ponieważ wpłynie to na resztę twojego zaplecza i albo ułatwi ci życie, albo doprowadzi cię do wyjścia z frustracji.

Zasadniczo SOA oznacza projektowanie usługi internetowej wokół procesów biznesowych, tj. Tego, jak ludzie, którzy używają Twojego interfejsu API, mogą z niej korzystać.

Dobry desgin jest zawsze dobrym pomysłem, więc bardzo polecam lekturę na temat zasad projektowania Web Sevice przed rozpoczęciem kodowania i uratuj siebie lub inne nieszczęśliwe dupy dużo później.

Upewnij się także, że Twój projekt jest sprawny, ponieważ będzie się często zmieniać, gdy będzie się odbywać komunikacja między Twoją firmą a Twoimi klientami.

Answer 4

Trochę bardziej związany z implementacją niż z projektem: Postanowiłbym, że wyjście z usługi będzie XML - może to być bardzo łatwe do przeanalizowania przez wszystkie przyzwoite języki. Ponadto, jeśli jakiś klient potrzebuje innego wyjścia, możesz przekształcić te XML-y za pomocą niektórych procesorów XSLT i zaoferować "inne" usługi internetowe, które wyprowadzają JSON, lub cokolwiek innego, czego potrzebują. Jeśli chodzi o raportowanie, zależy to od tego, w jaki sposób będą używane raporty - jeśli klienci je przetwarzają i potrzebują tylko danych z raportów - ponownie sugerują XML. Moim zdaniem praca z CSV jest trudniejsza, ponieważ trzeba wziąć pod uwagę wszystkie specjalne przypadki, takie jak "co się stanie, jeśli moje dane zawierają pole separatora", "czy klient będzie w stanie określić separator", "jak będę reprezentował zagnieżdżone dane "lub wszystkie z nich są proste z XML. Jeśli Twój klient potrzebuje raportów, aby użyć ich po wyjęciu z pudełka, możesz użyć BIRT -pięknego i darmowego

Answer 5

Oferowanie wielu wyjść, takich jak JSON, CSV, YAML lub XML jest dobre - to daje użytkownikowi końcowemu komfort, na bardzo małym koszt! Przesyłanie danych jest zawsze łatwiejsze niż przetwarzanie i mówimy, że już z jakiegoś powodu parsują JSON - o wiele łatwiej jest po prostu połączyć to z API niż zaimplementować, na przykład parser XML. Obecnie wszędzie widzę parsery XML, więc prawdopodobnie nie powinno to stanowić problemu, ale podoba mi się bardziej "powietrzna" natura JSON; Spojrzałem trochę na YAML, ale nigdy go nie użyłem - ale wygląda obiecująco, definitywnie użyję tego dla plików konfiguracyjnych mojego następnego projektu.

Po stronie bezpieczeństwa wszystkiego, co dynamicznie przetwarza dane wejściowe, które podaje użytkownik, należy traktować takie dane wejściowe jak coś, czego nie można by podsłuchać nawet przy pomocy patyka.

Bezstanowy status IMHO REST jest lepszy niż SOAP, ponieważ jest mniejszy narzut, można łatwo komunikować się z interfejsem REST-api ręcznie za pomocą curl lub wget z terminala. Zacznij więc mówić.

Polecam, aby wziąć głęboki oddech, ołówek & papieru, usiądź i szkicuj wszystko, co będzie potrzebne. Następnie usuń mniej ważne rzeczy, weź nowy papier i zacznij go organizować. Możesz dodać mniej ważne rzeczy w następnej wersji interfejsu API.

Spróbuj zaprojektować interfejs API, tak abyś nie zamykał się w kącie, nie zakładaj, dokąd zmierza.