Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

> Zasady pisania na forum Pro

Tematy na forum Pro mogą zakładać jedynie moderatorzy. W otwartych tematach może pisać każdy, kto ma coś fachowego do powiedzenia. Wszystkie posty nie wnoszące nic do tematu będą natychmiast usuwane, a ich autorzy dostaną ostrzeżenie.
Jeśli uważasz, że jakiś temat jest warty dyskusji na tym forum, zgłoś go w temacie Propozycje.

2 Stron V   1 2 >  
Reply to this topicStart new topic
> API do wykorzystania przez zewnętrzne serwisy
nospor
post 16.02.2009, 08:11:30
Post #1





Grupa: Moderatorzy
Postów: 36 432
Pomógł: 6289
Dołączył: 27.12.2004




Temat otwarty, zapraszam do dyskusji


--------------------

"Myśl, myśl, myśl..." - Kubuś Puchatek || "Manual, manual, manual..." - Kubuś Programista
"Szukaj, szukaj, szukaj..." - Kubuś Odkrywca || "Debuguj, debuguj, debuguj..." - Kubuś Developer

Go to the top of the page
+Quote Post
Zigi
post 16.02.2009, 20:54:13
Post #2





Grupa: Zarejestrowani
Postów: 57
Pomógł: 3
Dołączył: 20.11.2004

Ostrzeżenie: (0%)
-----


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

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?
Go to the top of the page
+Quote Post
webdevil
post 16.02.2009, 21:07:20
Post #3





Grupa: Zarejestrowani
Postów: 82
Pomógł: 18
Dołączył: 2.02.2009

Ostrzeżenie: (0%)
-----


Cytat(Zigi @ 16.02.2009, 20:54:13 ) *
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
Go to the top of the page
+Quote Post
Siela
post 16.02.2009, 21:30:34
Post #4





Grupa: Zarejestrowani
Postów: 27
Pomógł: 1
Dołączył: 28.02.2005
Skąd: Gdańsk

Ostrzeżenie: (0%)
-----


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?
Go to the top of the page
+Quote Post
bigZbig
post 19.02.2009, 15:24:25
Post #5





Grupa: Zarejestrowani
Postów: 740
Pomógł: 15
Dołączył: 23.08.2004
Skąd: Poznań

Ostrzeżenie: (0%)
-----


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 winksmiley.jpg (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.


--------------------
bigZbig (Zbigniew Heintze) | blog.heintze.pl
Go to the top of the page
+Quote Post
Strzałek
post 5.03.2009, 17:59:51
Post #6





Grupa: Przyjaciele php.pl
Postów: 384
Pomógł: 6
Dołączył: 11.09.2004
Skąd: Grodzisk Mazowiecki

Ostrzeżenie: (0%)
-----


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.


--------------------
Go to the top of the page
+Quote Post
Zigi
post 8.03.2009, 10:24:38
Post #7





Grupa: Zarejestrowani
Postów: 57
Pomógł: 3
Dołączył: 20.11.2004

Ostrzeżenie: (0%)
-----


Cytat(webdevil @ 16.02.2009, 21:07:20 ) *
Proste pytanie - tak żeby API było tylko drugą warstwą prezentacyjną - żeby nie trzeba było pisać 2 razy tych samych funkcjonalności


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ć?
Go to the top of the page
+Quote Post
bigZbig
post 8.03.2009, 11:40:41
Post #8





Grupa: Zarejestrowani
Postów: 740
Pomógł: 15
Dołączył: 23.08.2004
Skąd: Poznań

Ostrzeżenie: (0%)
-----


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.


--------------------
bigZbig (Zbigniew Heintze) | blog.heintze.pl
Go to the top of the page
+Quote Post
Zigi
post 10.03.2009, 13:38:33
Post #9





Grupa: Zarejestrowani
Postów: 57
Pomógł: 3
Dołączył: 20.11.2004

Ostrzeżenie: (0%)
-----


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?
Go to the top of the page
+Quote Post
AxZx
post 10.03.2009, 14:15:43
Post #10





Grupa: Zarejestrowani
Postów: 1 385
Pomógł: 55
Dołączył: 1.03.2005
Skąd: śląsk

Ostrzeżenie: (0%)
-----


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.


--------------------
aplikacje internetowe | Symfony
Go to the top of the page
+Quote Post
LBO
post 21.03.2009, 14:04:36
Post #11





Grupa: Zarejestrowani
Postów: 1 415
Pomógł: 117
Dołączył: 7.09.2005
Skąd: Warszawa

Ostrzeżenie: (0%)
-----


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.
Go to the top of the page
+Quote Post
nasty
post 1.04.2009, 23:55:08
Post #12





Grupa: Zarejestrowani
Postów: 634
Pomógł: 14
Dołączył: 27.05.2006
Skąd: Berlin

Ostrzeżenie: (0%)
-----


Cytat(AxZx @ 10.03.2009, 15:15:43 ) *
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.


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-*.
Go to the top of the page
+Quote Post
Elf
post 26.06.2009, 23:16:55
Post #13





Grupa: Zarejestrowani
Postów: 5
Pomógł: 0
Dołączył: 24.07.2007

Ostrzeżenie: (0%)
-----


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.
Go to the top of the page
+Quote Post
skrypta
post 1.07.2009, 23:46:17
Post #14





Grupa: Zarejestrowani
Postów: 16
Pomógł: 0
Dołączył: 1.07.2009

Ostrzeżenie: (0%)
-----


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...


--------------------
Skrypta.pl - Blog developerski PHP, MySQL, AJAX, Pozycjonowanie SEO, optymalizacja
Kopruch.pl - T-shirts i koszulki dla webmasterów, programistów i administratorów
Go to the top of the page
+Quote Post
erix
post 2.07.2009, 10:10:49
Post #15





Grupa: Moderatorzy
Postów: 15 467
Pomógł: 1451
Dołączył: 25.04.2005
Skąd: Szczebrzeszyn/Rzeszów




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


--------------------

ZCE :: Pisząc PW załączaj LINK DO TEMATU i TYLKO w sprawach moderacji :: jakiś błąd - a TREŚĆ BŁĘDU? :: nie ponaglaj z odpowiedzią via PW!
Go to the top of the page
+Quote Post
batman
post 2.07.2009, 11:58:47
Post #16





Grupa: Moderatorzy
Postów: 2 921
Pomógł: 269
Dołączył: 11.08.2005
Skąd: 127.0.0.1




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.


--------------------
I would love to change the world, but they won't give me the source code.
My software never has bugs. It just develops random features.
Go to the top of the page
+Quote Post
basso
post 28.11.2012, 22:45:31
Post #17





Grupa: Zarejestrowani
Postów: 155
Pomógł: 1
Dołączył: 12.12.2010

Ostrzeżenie: (0%)
-----


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 ...
Go to the top of the page
+Quote Post
ViX
post 26.04.2013, 11:06:06
Post #18





Grupa: Zarejestrowani
Postów: 114
Pomógł: 9
Dołączył: 19.11.2007
Skąd: Kraków

Ostrzeżenie: (0%)
-----


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.


--------------------
Poszukujący wiedzy
Go to the top of the page
+Quote Post
cadavre
post 26.07.2013, 19:12:11
Post #19





Grupa: Zarejestrowani
Postów: 472
Pomógł: 7
Dołączył: 7.12.2005
Skąd: Gliwice

Ostrzeżenie: (0%)
-----


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

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. smile.gif

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.


--------------------
Silesian PHP User Group - www.spug.pl
Symfony2, OAuth2, budowanie API - masz pytania? Pisz!
Go to the top of the page
+Quote Post
Kalinowcyk
post 2.09.2014, 21:28:48
Post #20





Grupa: Zarejestrowani
Postów: 67
Pomógł: 4
Dołączył: 23.09.2008

Ostrzeżenie: (0%)
-----


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.


--------------------
Notatnik programisty
Go to the top of the page
+Quote Post

2 Stron V   1 2 >
Reply to this topicStart new topic
1 Użytkowników czyta ten temat (1 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Wersja Lo-Fi Aktualny czas: 19.03.2024 - 11:52