Stosujesz projekt RESTful na całej stronie?

To wszystko może się wydać bardzo nowatorskie, ale staram się zapanować nad projektowaniem strony internetowej, która jest całkowicie RESTful. Rozumiem stosowanie RESTful design do takich rzeczy jak użytkownicy, zdjęcia, posty na blogach itp., Ponieważ myślę o nich jak o „obiektach”.

Ale co ze stroną „o nas”. Co to za zasób? Czy jest to nawet zasób w ODPOWIEDNIM znaczeniu tego słowa? Powiedzmy też, że przechodzę do adresu URL „http://www.example.com/”, o jakie zasoby proszę? Zasób indeksu?

Najczęstszym wzorcem zasobów witryny RESTful, który widzę, jest dodanie widoku do identyfikatora URI:

/ resourcetype / identifier [/ view ] [/ page] [? filterparams]

Gdy nie ma widoku , po prostu podajesz widok domyślny. W Twoim przypadku:

• / - prośba o example.comzwrócenie domyślnego widoku zasobu najwyższego poziomu - Twojej witryny.
• / aboutus - widok zasobu najwyższego poziomu „O nas”. Lub alternatywnie aboutusmoże być nazwanym identyfikatorem zasobu w zakresie CMS najwyższego poziomu. *
• / klienci / 1 / aboutus - ta prośba oznaczałaby widok „O nas” obejmujący klienta 1 .

Biorąc to pod uwagę, czasami najlepiej jest trochę podkręcić dla lepszej semantyki. Na przykład StackOverflow używa RESTful / pytania / [id] do pytań, ale strona Zadaj pytanie to / pytania / pytaj, która nie jest bardzo RESTful ( asknie jest questionszasobem), ale ma sens używanie zwykłych śmiertelników.

^{* W CMS na najwyższym poziomie typ zasobu jest często, ale nie zawsze, usuwany, ponieważ jest nadmiarowy.}

Należy pamiętać, że projekt RESTful jako taki ma zapewnić standard, dzięki któremu sieć staje się jednolicie programowalna. Nie zawsze odpowiednie lub przydatne jest klaksonowanie całej witryny skierowanej do ludzi w czystą semantykę REST.

Gdy masz zasoby, warto wziąć pod uwagę ich reprezentacje. Ważne jest również, aby wziąć pod uwagę inne zasady projektowania REST, takie jak bezpaństwowcy, oraz ich wpływ na wydajność i użyteczność witryny. Pamiętaj jednak, że REST jest narzędziem, a nie celem. To środek, a nie koniec.

Używaj semantyki RESTful tam , gdzie jest to przydatne , po zrozumieniu ich celu i korzyści, i nie przejmuj się, jeśli Twoja witryna nie jest w pełni RESTful. W każdym razie byłoby to prawie niemożliwe dla każdej nietrywialnej witryny.

TL; DR : REST to narzędzie. Używaj go, kiedy i gdzie jest to przydatne, ale nie daj się związać.

Ale co ze stroną „o nas” [?] Co to za zasób?

Złożony. Nie ma nic złego w zasobach, które mają komponenty, elementy lub strukturę.

Zasoby nie są „wierszami relacyjnej bazy danych” ani innymi atomowymi rzeczami. Są zasobami.

Zorientowane na dokumenty bazy danych radzą sobie z tym bardziej płynnie, ponieważ zasób może być większy i bardziej uporządkowany.

Czy jest to nawet zasób w ODPOWIEDNIM znaczeniu tego słowa?

Tak.

Powiedzmy też, że przechodzę do adresu URL „http://www.example.com/”, o jakie zasoby proszę?

Nie.

Pytasz o zasób „aboutus”. Jest możliwe (ale nieparzyste), że zasób może być singletonem. Bez identyfikatora, a nie „lista”.

http://www.example.com/aboutus/?format=xml

Zwraca złożony dokument XML z dużą ilością części i części. Nic w tym złego.

Zasób indeksu?

Nie znaczy wiele w sensie „RESTful”. Strona „Indeks” jest przeznaczona dla ludzi. Aplikacja korzystająca z interfejsu API RESTful została zaprojektowana do żądania określonych rodzajów zasobów.

Chciałbym zachować mój pogląd niezależny od zaplecza. Możesz poprosić zaplecze o zasoby, takie jak rzeczy na akordeonie, pasek nawigacyjny i inne przedmioty dotyczące ciała. Jednak przetwarzanie tych reprezentacji zasobów należy pozostawić kodowi klienta, który ostatecznie je wyrenderuje zgodnie z wymaganiami.

Zasobem dla „O nas” jest ... My :) er, You. Pomyśl o atrybutach Ciebie, które chcesz opublikować, i zwiń je jako rzeczownik z reprezentacją.

Te wartości nie muszą pochodzić z bazy danych ... prawdopodobnie będzie to zbiór ciągów znaków, a te mogą pochodzić z config, a może nawet zakodowane na stałe w klasie.