Używanie czasowników HTTP LINK i UNLINK w interfejsie API REST

Obecnie pracuję nad implementacją interfejsu API REST. Mam model zasobów z dużą liczbą relacji między poszczególnymi zasobami.Używanie czasowników HTTP LINK i UNLINK w interfejsie API REST

Moje pytanie brzmi: w jaki sposób połączyć dwa istniejące zasoby ze sobą nawzajem (ustanawiając związek) w trybie RESTOWNOWYM?

Jednym z rozwiązań, na które natrafiłem, było użycie czasowników HTTP LINK i UNLINK. Konsument API będzie mógł połączyć dwa zasoby za pomocą LINK i następującego identyfikatora URI:/resource1 /: id1/resource2 /: id2.

Problem z tym rozwiązaniem polega na braku obsługi czasowników LINK i UNLINK. Ani http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html ani http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol nie wspominają o czasownikach i wydają się być w dużej mierze "zapomniane". Jednak oryginalny RFC 2068 stwierdza, że one istnieją.

Bardzo podoba mi się to rozwiązanie. Obawiam się jednak, że wielu klientów/klientów API nie będzie w stanie poradzić sobie z rozwiązaniem z powodu braku wsparcia dla LINK/UNLINK. Czy jest to dopuszczalne rozwiązanie, czy istnieją lepsze i/lub bardziej eleganckie rozwiązania do łączenia istniejących zasobów w RESTful API?

Dzięki

Źródło

2012-09-03 Jeroen Minnaert

Dlaczego nie utworzyć zasobu łącza, który łączy te dwa zasoby? –

To jest inne rozwiązanie, które rozważałem (jest to w dużej mierze rozwiązane w [tym pytaniu] (http://stackoverflow.com/questions/6324547/how-to-handle-many-to-many-relationships-in-a-refulful -api) Jednak problem polega na tym, że dla każdego rodzaju relacji należy zdefiniować nowy zasób (typ).To nadmiernie komplikuje model zasobów i nie jest szczególnie pragmatyczne (ponieważ twój klient API musi być świadomy o wiele więcej rodzajów zasobów). LINK/UNLINK nie komplikuje tego nadmiernie: nawiązanie relacji jest bardzo przewidywalne, a przez to łatwiejsze w użyciu. Jeśli jednak LINK/UNLINK nie są obsługiwane ... –

używam LINK i UNLINK w mojej firmie (zamówienie, wewnętrzne) aplikacji internetowej. Używam http://tools.ietf.org/html/draft-snell-link-method jako odniesienia do implementacji.

odkryłem, że istnieją trzy rodzaje klientów:

Te, które obsługują tylko GET i POST, biorąc ich repliki od <form> elementu HTML za.
Te, które obsługują tylko GET, PUT, POST i DELETE. Biorą one swoje sygnały z interfejsów API typu CRUD i RPC udających, że są to-REST.
Te, które pozwalają na dowolną metodę. Publikacja PATCH jako oficjalnego dokumentu RFC zwiększyła ich liczbę, podobnie jak wzrost WebDAV, chociaż czasami klienci kategorii 2 również obsługują PATCH.

Ponieważ obecnie rozwijamy naszych klientów w firmie, nie mamy tego problemu, ale przyjrzałem się temu i rozważyłem za i przeciw, zanim zdefiniowałem moje API, na wypadek gdybyśmy chcieli pozwolić na trzecie klienci imprezowi. Moje rozwiązanie (ponieważ musieliśmy w dalszym ciągu obsługiwać klientów HTML bez Javascript) miało umożliwić POST zastąpienie tej metody przez dostarczenie pola _METHOD (application/x-www-form-urlencoded), a następnie wyłączenie funkcji post() na tylnej części tylnej strony dla odpowiedniej funkcji dla zamierzonego Metoda HTTP. W ten sposób każdy klient w przyszłości, który jest, powiedzmy, klasy 2 powyżej, może używać PUT i DELETE, ale zawijać PATCH, LINK i w żądaniu POST. Dostajesz to, co najlepsze z obu światów: bogate metody od klientów, które je obsługują, a mimo to obsługują klientów o niskiej jakości poprzez tunelowanie POST.

Źródło

2013-06-10 09:09:08

Całkowicie zgadzam się z tą odpowiedzią. Skończyło się na tym, że wprowadziłem ją w życie już we wrześniu i cieszę się, że ktoś doszedł do tego samego wniosku. Dzięki! –

nie ma za co :) –

Używanie czasowników HTTP LINK i UNLINK w interfejsie API REST

Odpowiedz

Powiązane problemy