W notce Pingback w kilku słowach (cz. 1) zacząłem opisywać tworzenie serwera Pingback w Ruby on Rails. W tej chciałbym dokończyć opis tworzenia serwera, natomiast w następnej (może następnych?) przedstawię, jak stworzyć klienta i się nim posługiwać. Kontynuując tekst sprzed dwóch tygodni zakładam, że czytelnik pamięta o czym pisałem, szczególnie jeżeli chodzi o sam protokół Pingback 1.0. Zatem, do dzieła!
Pozostało nam właściwie napisanie tylko metody ping, która będzie wywołana przy pingowaniu. Zgodnie ze specyfikacją pobiera ona dwa argumenty: sourceURI i targetURI, tj. permalink do tekstu, w którym odwołujemy się do drugiego tekstu, oraz permalink do tekstu do którego się odwołujemy. Nasza metoda ping będzie metodą klasy Pingback, o której wspominałem już wcześniej. Zatem w fazie początkowej nasza klasa będzie wyglądała tak:
class Pingback < ActionWebService::Base
web_service_api PingbackApi
def ping(source, target)
end
end
Jak łatwo się domyślić web_service_api przypisuje naszemu serwisowi API zawarte akurat w klasie PingbackApi. Warto zauważyć, że metoda ping nie wygląda jakoś szczególnie - właściwie zasady jej definiowania są takie same, jak zwykłych metod w Ruby. Zatem ostatnio użyta R-wartość jest wynikiem działania metody, chyba że rzuci ona wyjątkiem. No właśnie - wyjątki typu XMLRPC::FaultException będą po prostu odpowiadały za zwrócenie poprzez XML-RPC informacji o błędzie. Jak można wyczytać w dokumentacji konstruktor tego wyjątku pobiera dwie wartości - numer błędu oraz komunikat przyjazny człowiekowi. Dzięki takiemu podejściu do XML-RPC praca znacznie się upraszcza - nie martwimy się o to, jak zakodować zwracane wartości, bo martwi się tym warstwa stojąca wyżej.
Teraz wystarczy do naszej metody dopisać odpowiednie operacje, które będą sprawdzały poprawność podanych danych i w odpowiednich miejscach rzucą wyjątkami bądź na końcu zwrócą jakąś wartość, najlepiej tekst, że wszystko się udało - najlepiej po angielsku. Listę błędów znaleźć można w specyfikacji protokołu Pingback 1.0, a można z niej również wywnioskować, co należy sprawdzić podczas pingowania. A sprawdzić należy - czy podane sourceURI rzeczywiście istnieje i zawiera adres do targetURI, czy targetURI istnieje itp. I to właściwie koniec pracy nad serwerem naszego serwisu - można łatwo sprawdzić, czy rzeczywiście serwer działa poprzez scaffolding - wystarczy wywołać w klasie XmlrpcController metodę web_service_Scaffold podając do zjedzenia nazwę akcji (w formie symbolu), która odpowiadać będzie za scaffolding. Przykład:
web_service_scaffold :invoke
Jeśli jesteś osobą, która wierzy, że wszyscy spiskują i nie należy wierzyć twórcom RoR, możesz również sprawdzić działanie serwisu pisząc odpowiednią aplikację - ja tak zrobiłem :).
