Restful web services

Question

Czego należy unikać przy ustawianiu interfejsu Restful, aby upewnić się, że nie został on przekształcony w RPC?

Answer 1

Do:

• Zaprojektuj swój wniosek być hypertext-driven (Hypermedia jako silnik Application państwa - hateoas).
• Poświęć więcej czasu i wysiłku na zidentyfikowanie zasobów i tworzenie typów mediów do ich reprezentowania.
• Pomyśl o całym identyfikatorze URI jako identyfikatorze zasobu i przyjmij, że zmieni się on w przyszłości.
• Zapewnij wszystkie opcje, aby kontynuować przez aplikację jako łącza w swojej reprezentacji.
• Pomyśl o swojej aplikacji jako stronie internetowej, która będzie "przeszukiwana" lub "przeglądana" przez klientów.
• Spróbuj napisać klienta dla swojego interfejsu API i poszukaj, gdzie występuje sprzężenie.

nie:

• Publish szablony URI w dokumentacji API. Jeśli na przykład musisz mieć szablony parametrów zapytania, upewnij się, że są one częścią definicji rodzaju mediów.
• Pomyśl o swojej aplikacji jako kolekcji URI, na którą działają cztery czasowniki.
• Podawać typy mime, takie jak "application/xml" lub "application/json" do klientów.

Aby użyć analogii, interfejs API powinien działać bardziej jak GPS dla klientów, a mniej jak mapa. Będziesz podawać klientom tylko nazwę pobliskiej ulicy.Ale od tej pory mogą robić tylko to, co aplikacja mówi, że mogą zrobić w dowolnym momencie.

Celem tego stylu jest zminimalizowanie sprzężenia między aplikacją a jej klientami. Całe sprzężenie powinno wystąpić w definicji rodzaju nośnika. Upraszcza to rozwój interfejsu API i zapewnia przyjemny mechanizm wersjonowania. Sprawia również, że znikają pytania dotyczące problemów takich jak paginacja.

Większość interfejsów API "RESTful" nie działa zgodnie z tym wzorcem. Jeśli tak, zobacz numer Sun Cloud API i jego backstory.

Answer 2

Rodzaj szerokiego pytania, ale spróbuję. Po pierwsze, używaj tylko czasowników HTTP, jak były zamierzone. Nie wysyłaj POST na adres URL z argumentem URL, który w zasadzie zastępuje POST i zmienia go w GET lub DELETE. Tak działa SOAP (wszystko jest POST).

Answer 3

Skorzystaj z podstawowego protokołu tam, gdzie to możliwe. Zamiast czasowników w twoim ładunku używaj (na przykład) metod HTTP GET, POST, PUT, DELETE. Twój URI powinien opisywać zasób, ale nie to, co z nim zrobić.

Answer 4

Niektóre z rzeczy, które chcesz uniknąć to:

• buforowanie Ignorując
• Tunneling wszystko przez GET (lub alternatywnie POST)
• Ignorując typy MIME

Istnieje dobry artykuł tutaj, który mówi o niektórych wzorcach antyspamowych:

http://www.infoq.com/articles/rest-anti-patterns

Answer 5

tym artykule szczegółowo pewne decyzje projektowe, które odróżniają RPC z REST:

http://www.pluralsight.com/community/blogs/tewald/archive/2007/04/28/47067.aspx

@ S.Lott: dzięki, szczerze myślałem, że pisał, że jako odpowiedź nie komentarz. Tracę moje marmury.