Usługi sieciowe - REST a PHP JSON RPC

Question

Pracuję nad projektem, w którym próbuję ujawnić funkcję oprogramowania. Zasadniczo mam skonfigurowany mój backend i myślałem o oddzieleniu frontendu od kodu backendu przy użyciu wiadomości JSON. Jestem nieco zdezorientowany co do różnicy między usługą a API. Wiem, że API można zbudować na bazie usług. Ale mam na myśli te dwa modele - aby uzyskać dostęp do profilu X za pomocą json-rpc

http://xyz.com/?request= {"jsonrpc": "2.0", "id": 1, "method": "getProfile", "params": { "id": "X"}}

lub powinno być jak ten przy użyciu reszta -

http://api.xyz.com/X

Thank You

Answer 1

"Usługa" kontra "API" to dość ogólnikowe pytanie. Często te dwa pojęcia są używane zamiennie. "REST" vs "RPC" jest nieco łatwiej wyjaśnić.

Zazwyczaj z usługą REST adres URL reprezentuje określony zasób, taki jak "użytkownik", "konto" itp. Zazwyczaj można tworzyć/pobierać/aktualizować/usuwać te zasoby za pomocą metod HTTP POST/GET/PUT/DELETE. Aby zaktualizować profil dla użytkownika 1125 może wysłać co następuje:

POST /user/1125 HTTP/1.1 
Host: wherever.com 
Content-type: application/x-www-form-urlencoded 

firstName=Davey&lastName=Jones&email=dj%40thebrineydeep.com 

Wszystko, co chciałem zrobić z użytkownikiem 1125, należy wysłać żądanie do tej samej zawartości. Są wyjątki i warianty tego pomysłu, ale to jest sedno tego.

Usługi RPC przypominają raczej korzystanie z biblioteki funkcji, która jest przypisana do określonego adresu URL. Możesz mieć cały szereg powiązanych funkcji związanych z adresem URL: /services/json. Następnie, jeśli chce zmienić profil na starym Davey Jones, byś:

POST /services/json HTTP/1.1 
Host: wherever.com 
Content-type: application/json 

{ "jsonrpc": "2.0", 
    "id": 1, 
    "method": "setProfile", 
    "params": [ 1125, 
    { "firstName": "Davey", 
     "lastName": "Jones", 
     "email": "dj@thebrineydeep.com" 
    } 
    ] 
} 

ja osobiście jak JSON-RPC lepiej ponieważ:

• nie muszę spróbować zmieścić wszystkie moje wywołania funkcji do pewnego rodzaju mapowania zasobu do adresu URL, które mogą nie mieć sensu.
• Nie próbujemy przeciążać kodów odpowiedzi HTTP, aby wskazać błędy interfejsu API. Każde żądanie zwraca odpowiedź 200 (chyba że wystąpił błąd serwera) i na podstawie treści odpowiedzi wiesz, czy wystąpił błąd, czy nie. JSON-RPC jest szczególnie dobry w byciu jednoznacznym na temat warunków błędu.

Czasami REST jest lepsza, ponieważ:

• Czasami mapowanie zasobów do adresu URL pasuje bardzo dobrze
• Jest bardziej intuicyjny dla osób trzecich do zrozumienia
• Oferuje on prostszy model po prostu odzyskiwanie łatwo rozpoznawalnych informacji

Nie sądzę, aby jedno z nich było łatwiejsze do kodu.

Edycja Zmieniłem przykład REST, aby użyć bardziej typowych danych zakodowanych w formie zamiast JSON. Ale oczywiście możesz określić dowolny format danych, który chcesz z REST. Nie jest wyryte w kamieniu.

Answer 2

odpocząć URL nie równa żądania JSON-RPC.

Przynajmniej powinno być http://api.example.org/getProfile?id=X

Tam naprawdę nie ma dużej różnicy między nimi. A Twój "REST" nie jest prawdziwym REST, chyba że zwrócisz format danych, który w niezawodny sposób może wyrażać linki do różnych adresów URL, np. XML lub (X) HTML. Dopóki to wymaganie nie zostanie spełnione, powinieneś go nazwać "RESTful", ponieważ naprawdę używasz tylko metod HTTP do wyzwalania rzeczy i przenoszenia danych tam iz powrotem.

Nie ma znaczenia, z czego korzystasz - chyba że znasz lub masz doświadczenie z oprogramowaniem, które pomaga w szybszym budowaniu jednego lub drugiego rozwiązania.