Temat otwarty, zapraszam do dyskusji

Chciałbym bardzo podziękować za stworzenie tego tematu

To może ja zaczne. Na jakim protokole najlepiej obecnie się skupić przy tworzeniu zewnętrzego API? OPML, SOAP, XML-RPC czy też może jakiś inny?

Jak budować serwis, aby dodawanie API stawarzło jak najmniej problemów?

Proste pytanie - tak żeby API było tylko drugą warstwą prezentacyjną - żeby nie trzeba było pisać 2 razy tych samych funkcjonalności

Ja się chętnie podepnę pod temat. W sumie nigdy nie interesowałem się takimi rzeczami, ale ostatnio mnie naszło. Wiem, że Allegro zrobiło API w oparciu o SOAP, ale jak wyczytałem później można to jeszcze innymi sposobami wykonać.

O czym powinienem poszukać informacji jeśli potrzebuje API z przymusem autoryzacji do wykonania co poniektórych metod? Jest jakiś bezpieczniejszy sposób czy każdy po prostu w pewien sposób umożliwia zabezpieczenie API.

Co radzicie?

Ja mam niewielkie doświadczenie z SOUP-em (dwa poważne projekty). Php ma całkiem fajne rozszerzenie do SOUP-a i WSDL-a http://pl.php.net/manual/pl/book.soap.php. Troszkę mi to krwi napsuło dopóki nie opanowałem trudnej sztuki debugowania (z AJAX-em miałem to samo) W gruncie rzeczy proste w użyciu, a przy pomocy odrobiny magi (funkcje magiczne mam na myśli) to można osiągnąć naprawdę fajne efekty.

Jestem ciekaw Waszej opinii na temat innych API, a także stosowanych przez was rozwiązań - zwłaszcza dotyczących bezpieczeństwa.

Jeżeli chodzi o bezpieczeństwo API - [link=http://oauth.net/]oAuth[/link]

Jeżeli chodzi o wybór - XML. Czemu? Bo jest najbardziej dostępny. Każdy umie go przeparsować, nie potrzeba dodatkowych bibliotek. Nawet w js obsłużymy sprawnie drzewo XML używając DOM.

To jest bardzo dobry pomysł tylko jak to zrealizować w praktyce? Załóżmy, że chcemy dodać API do stronki tworzonej w tym artykule http://wortal.php.pl/wortal/artykuly/frame..._zend_framework
Warstwą w jakiej powinno był przetwarzane żądanie jest chyba kontroler.?
Najbardziej naturalne wydaje mi się dodanie jakiejś stałej np. API_REQUEST i w zależności czy wywołanie jest przez użytkownika czy przez API wykonują się odpowiednie instrukcje. Tylko czy taki las IFów nie zaciemni za bardzo kodu. Ma ktoś pomysł jak to rozwiązać?

U mnie to wyglądało tak, że tworzyłem kontrolery specjalnie dla soupa, które de facto odpowiadały modelom w mojej aplikacji czyli. Metoda w kontrolerze odpowiadała metodzie w modelu. W ten sposób serwis który pobierał dane za pośrednictwem soupa dostawał je w takiej postaci, jakby je pobierał bezpośrednio z BD. Oczywiście lista metod była z góry ustalona i nie można było za pomocą soupa budować zapytań at hock. Ze względów bezpieczeństwa możliwe było tylko wywołanie określonych metod modelu ze ścisłą kontrolą przesyłanych parametrów. Metody te zwracały określone porcje danych.

Miałbym do Ciebie pytanie @bigZbig w jaki sposób tworzysz główny plik po stronie serwera odpowiedzialny za udostępnianie API?

Ja dodaje funkcje za pomocą metody addFunction" title="Zobacz w manualu PHP" target="_manual z klasy SoapServer" title="Zobacz w manualu PHP" target="_manual i w każdej funkcji includuje plik kontrolera a następnie wywołuję odpowiednia metode z tego kontrolera. Tutaj też mam pytanie, czy takie postępowanie jest optymalne, bo mam co do tego wątpliwości?

jako format wymiany danych ja bardziej skłaniam się do używania JSON. mniej danych, szybsze parsowanie, łatwiejsza obsługa.

czy API ma korzystać z tych samych kontrolerów i akcji, z których korzysta główna aplikacja? ja mam wątpliwości, bo przecież akcje głównej aplikacji są bardziej złożone - pobieranie większej ilości różnych danych itd.
czyli do API osobny kontroler lub osobne akcje w kontrolerach.

API powinno się opierać na już istniejących akcjach. Fakt, czasem trzeba stworzyć dodatkowe specjalnie dla np. SOAP ale tylko dlatego, że w requeście www taka akcja byłaby niepraktyczna.

Tyle, że sam JSON, nie daję tylu możliwości co SOAP. Cieżko w nim używać np. WS-ReliableMessaging albo dużej (jak nie całej) reszty WS-*.

Rozdzielmy tutaj dwie rzeczy: API oraz udostępnianie danych. Jesli potrzebujemy głównie tego drugiego to XML, JSON itp. jest najlepszym wyborem. SOAP tu się nie sprawdza. W obecnej firmie mam webservice zajmujący się obliczaniem i udostępnianiem danych i SOAP daje zbyt duży narzut po stronie serwera (nuSOAP to potrafi pamięci zeżreć) jak i klienta. Na szczęscie jest też webpull zwracający zwykły XML bez zbędnych udziwnień i to działa świetnie.

Jestem zwolennikiem REST, jako naturalnej architektury dla sieci. Radzę wziąć ten styl pod uwagę przy wymyslaniu wlasnego API. Bardzo często wymyślne funkcje są niepotrzebne a większość interakcji da się zalatwić za pomocą staromodnych HTTP request & response.

SOAP, bedący tak naprawdę XML-RPC na sterydach, przydaje się głównie w złożonych systemach klasy enterprise, gdzie naprawdę trzeba wykonać jakieś akcje w zdalnym systemie żeby zmienić jego stan. To jednak nie do końca przystaje do architektury Web (np. jeden endpoint dla wszystkich żądań), która to jest oparta na zasobach identyfikowanych przez URI. Temat rzeka, ale polecam poszukać informacji o RESTful web services.

Przytocze przyklad API, produkt Basecamp ze stajni 37signals
Uzywaja XML, a z bezpieczenstwem? trzeba sie autoryzowac w API przesylajac login i haslo w GET, oficjalny manual Basecamp poleca CURL'a, dyskusyjne podesjcie, ktorego jak widac ten gigant sie nie boi...

Nie dyskusyjne, gdyż chcą umożliwić innym developerom integrację z jak największą ilością zewnętrznych aplikacji.

Skoro temat został odgrzebany, to oddam swój głos na SOAP.
Stworzyłem kilka web service-ów w oparciu w SOAP i nie miałem z tym protokołem żadnych problemów. Bezpieczeństwo mam zapewnione poprzez sesje, więc zanim ktoś będzie mógł skorzystać z moich metod, musi się zalogować. Nie sprawdzałem jeszcze połączeń szyfrowanych, więc z chęcią poznałbym wady i zalety takiego rozwiązania.
Najlepsze w SOAP jest to, że znaczący język potrafi się komunikować przy jego pomocy.

Wspomniano, że użycie usługi sieciowej może spowodować zdublowanie kodu. Rzeczywiście jest takie ryzyko, jednak można nad nim zapanować. Najlepszym rozwiązaniem jest zaplanowanie całej aplikacji przed napisaniem pierwszego wiersza kodu. Dobrze przemyślana aplikacja pozwoli uniknąć pisania jednej funkcjonalności dwa razy. Dobrym rozwiązaniem jest stworzenie klasy, która będzie korzystała z gotowych modeli, do przetworzenia żądania i zwrócenia odpowiedzi.

Witam,
A co z wydajnością ?
Stawiał ktoś scentralizowane backendy i frontendy?
Zastanawiam się nad stworzeniem CMS-a scentralizowanego + front.

Boję się, że to nie wydoli ...

Z mojego doświadczenia wynika, że API do pobierania danych najlepiej jest napisać na JSON'ie. PHP, JS, Python i wiele innych języków świetnie radzi sobie z tym formatem.
Dodatkowo ma mały narzut w porównaniu z XML'em. Jednakże część firm życzy sobie otrzymywać dane w XML'u dlatego najlepiej jest jako parametr podać format.
Po stronie kontrolera wystarczy przygotować komponent, który zajmie się odpowiednim sposobem prezentacji danych jako JSON lub XML.

Ciekawy temat... szkoda tyle, że tak mało napisane.

Ja od jakiegoś czasu nie robię praktycznie nic poza pisaniem API na potrzeby różnych projektów. Generalnie API dzielą się na dwa lub trzy typy:
1. API które służą wyłącznie dostarczaniu danych, wcześniej wprowadzonych przez administratora.
2. API które ze swojej strony oferują tylko MC warstwę CRUD.
3. API które oferują pełny CRUD wraz z VC do administracji zasobami.

Pierwszy i drugi przypadek praktycznie zawsze realizuję czysto RESTfulowo, format danych JSON lub XML - każde przyzwoicie napisane API powinno być na tyle elastyczne by nie mieć problemu z dostarczaniem danych w obu tych formatach - w zależności od zapotrzebowań. JSON jest ostatnio w modzie, bardzo łatwo go parsować, nie jest transfero-żerny - to też w większości przypadków jest to format sugerowany.

Początkowo myślałem, że REST sam w sobie jest banalną ideą - po dwóch projektach okazało się, że jest mnóstwo rzeczy, które można zrobić lepiej, a co ważniejsze - zgodnie z pewnymi standardami.

Jeśli chodzi o zabezpieczanie API - najlepszy sposobem zawsze okazuje się oAuth v2, dzięki różnym metodom uzyskiwania tokenów dostępu oraz prostej autoryzacji (stateless) Bearerem przekazywanym w nagłówkach Requestu.

Ja opieram się o SOAP, a do generowania WSDL wykorzystuję Zend -> Autodiscover.
Przykład można zobaczyć tutaj: link

Polecam takie rozwiązanie - zero problemów. Piszesz metodę i już jest dostępna w API.
Do autoryzacji wykorzystuję sesje HTTP.

Laravel pozwala dosłownie w kilka dni stworzyć RESTful API wcale nie męcząc się za bardzo.