REST-złożone aplikacje

"Filtr jako zasób" jest do tego idealnym taktem.

Możesz umieścić definicję filtra w zasobie filtra i może on zwrócić identyfikator filtra.

PUT jest idempotentny, więc nawet jeśli filtr już tam jest, Musisz tylko wykryć, że widziałeś filtr wcześniej, więc możesz zwrócić odpowiedni identyfikator dla filtra.

Następnie możesz dodać parametr filtra do innych żądań, a oni mogą pobrać filtr, aby użyć go do zapytań.

GET / leki?filter=1234&page=4&pagesize=20

Chciałbym uruchomić filtry raw przez jakiś proces kanoniczny, po prostu mieć znormalizowany zestaw, tak, że np filtr "firstname=Bob Lastname=Eubanks" jest identyczny z "LastName=Eubanks firstname=Bob". To tylko ja.

Jedynym problemem jest to, że w miarę upływu czasu może być konieczne zdezaktualizowanie niektórych filtrów. Możesz po prostu popełnić błąd w żądaniu, jeśli ktoś zgłosi żądanie z brakującym lub przestarzałym filtr.

Edytuj odpowiedź na pytanie...

Zacznijmy od podstaw.

Po prostu chcesz określić filtr do użycia w zapytaniach, ale te filtry są (potencjalnie) zaangażowane i skomplikowane. Gdyby to było proste / 1234, to nie byłoby problemu.

Skutecznie, zawsze trzeba wysłać filtr do zapytania. Pytanie brzmi, jak reprezentować ten filtr.

Podstawowym problemem takich rzeczy jak sesje w systemach REST jest to, że są zazwyczaj zarządzane "poza pasmem". Kiedy, powiedzmy, idziesz i tworzysz lek, umieszczasz lub publikujesz w zasobie leków i dostajesz odniesienie do tego leku.

W przypadku sesji (zazwyczaj) odzyskasz plik cookie lub inny token do reprezentowania tej sesji. Jeśli twój wkład do zasobów leków stworzył również Sesję, to w rzeczywistości twoja prośba stworzyła dwa zasoby: lek i sesję.

Niestety, gdy używasz czegoś takiego jak plik cookie, a ty potrzebujesz tego pliku cookie do swojego żądania, nazwa zasobu nie jest już prawdziwą reprezentacją zasobu. Teraz jest to nazwa zasobu (adres URL) i plik cookie.

Więc, jeśli zrobić dostać na zasobu o nazwie / leki / Szukaj, a plik cookie reprezentuje sesję, a ta sesja dzieje się mieć filtr w nim, można zobaczyć, jak w efekcie, że nazwa zasobu, / leki / szukaj, nie jest naprawdę przydatne w ogóle. Nie mam wszystkich informacji, które są mi potrzebne do skutecznego działania. korzystania, ze względu na efekt uboczny cookie i sesji oraz filtr w niej zawarty.

Mógłbyś może przepisać nazwę:/leki / Szukaj?session = ABC123, skutecznie osadzając plik cookie w nazwie zasobu.

Ale teraz biegniesz do typowego kontraktu sesji, zwłaszcza, że są one krótkotrwałe. Tak więc ten nazwany zasób jest mniej przydatny, długoterminowy, nie bezużyteczny, po prostu mniej przydatny. W tej chwili to zapytanie daje mi interesujące dane. Jutro? Pewnie nie. Przyniosę. paskudny błąd dotyczący zniknięcia sesji.

Innym problemem jest to, że sesje zazwyczaj nie są zarządzane jako zasób. Na przykład są one zwykle efektem ubocznym, a nie jawnie zarządzane przez GET/PUT / DELETE. Sesje są również "kupą śmieci" stanu aplikacji internetowej. W tym przypadku mamy tylko nadzieję, że sesja jest odpowiednio wypełniona tym, co jest potrzebne do tego żądania. Właściwie to nie wiemy. Znowu, to efekt uboczny.

Teraz obróćmy go trochę na głowę trochę. Let ' s use / leki / Szukaj?filtr = ABC123.

Oczywiście, od niechcenia, to wygląda identycznie. Właśnie zmieniliśmy nazwę z "session" na "filter". Ale, jak wspomniano, Filtry w tym przypadku są "zasobem pierwszej klasy". Muszą być tworzone, zarządzane itp. tak samo jak leki, pliki JPEG lub inne zasoby w Twoim systemie. To jest kluczowe rozróżnienie.

Oczywiście, można traktować "sesje" jako zasoby pierwszej klasy, tworząc je, umieszczając w nich rzeczy bezpośrednio itp. Ale widać, że, przynajmniej z punktu widzenia jasności, sesja "pierwszej klasy" nie jest naprawdę dobrą abstrakcją dla tego przypadku. Korzystanie z sesji, to jak pójście do pralni i przekazanie całej torebki lub teczki. "Tak, bilet jest gdzieś tam, wykop co chcesz, daj mi moje ubrania", zwłaszcza w porównaniu do czegoś wyraźnego jak filtr.

Widać więc, że przy 30 000 stopach nie ma dużej różnicy między filtrem a sesją. Ale kiedy przybliżasz, są zupełnie inne.

Z zasobem filtrów, możesz wybrać, aby stały się trwałe na zawsze i na zawsze. Możesz je wygasnąć, możesz robić, co chcesz. Sesje mają zazwyczaj wstępnie pomyślaną semantykę: krótkie życie, czas trwania połączenia itp. Filtry mogą mieć dowolną semantykę. Są całkowicie oddzielone od tego, co wiąże się z sesją.

Gdybym to robił, jak pracowałbym z filtrami?

Zakładam, że naprawdę nie dbaj o zawartość filtra. W szczególności wątpię, czy kiedykolwiek zapytałbym o "wszystkie filtry, które przeszukują po imieniu". W tym momencie wydaje się to nieciekawą informacją, więc nie będę projektował wokół niej.

Następnie chciałbym normalizować filtry, jak wspomniałem powyżej. Upewnij się, że równoważne filtry naprawdę są równoważne. Możesz to zrobić sortując wyrażenia, upewniając się, że nazwy pól są wielkimi literami lub cokolwiek innego.

Wtedy zapisałbym filtr jako XML lub JSON dokument, w zależności od tego, co jest bardziej wygodne/odpowiednie dla aplikacji. Dałbym każdemu filtrowi unikalny klucz (naturalnie), ale również przechowywałbym hash dla rzeczywistego dokumentu z filtrem.

Zrobiłbym to, aby móc szybko znaleźć, czy filtr jest już zapisany. Ponieważ normalizuję to, "Wiem", że XML (powiedzmy) dla logicznie równoważnych filtrów byłby identyczny. Tak więc, gdy ktoś idzie umieścić, lub wstawić nowy filtr, chciałbym zrobić sprawdzenie na hash, aby zobaczyć, czy został przechowywany wcześniej. Mogę wrócić więcej niż jeden (hasze mogą się kolidować, oczywiście), więc będę musiał sprawdzić rzeczywiste ładunki XML, aby zobaczyć, czy pasują.

Jeśli filtry pasują, zwracam odniesienie do istniejącego filtra. Jeśli nie, stworzyłem nowy i zwróciłem go.

Nie pozwoliłbym również na aktualizację/POST filtra. Ponieważ rozdaję odniesienia do tych filtrów, uczyniłbym je niezmiennymi, aby odniesienia mogły pozostać ważne. Gdybym chciał filtrować po "roli", powiedzmy, " get all expireate medicines filter", wtedy stworzyłbym zasób "named filter", który kojarzy nazwę z instancją filtra, tak aby rzeczywiste dane filtra mogły się zmienić, ale nazwa pozostaje taka sama.

Pamiętaj również, że podczas tworzenia jesteś w stanie rasowym( dwa żądania próbują zrobić ten sam filtr), więc musisz to wyjaśnić. Jeśli system ma dużą objętość filtra, może to być potencjalne wąskie gardło.

Mam nadzieję, że to wyjaśni ci problem.