Projektowanie relaksującego adresy URL stron internetowych

Question

Większość REST tutoriale ułożone zasobów w następujący sposób:

GET /car/  -> list of cars 
GET /car/<id>/ -> info about specific car 
POST /car/  -> create a new car 

ale przy budowaniu aplikacji internetowych do wykorzystania w przeglądarkach, jest brakującym ogniwem, które są rzadko omawiane, przed wysłaniem do/samochód /, musisz zdobyć formularz do stworzenia nowego zasobu (samochód). Jaki powinien być adres URL tego formularza?

ja zwykle używane:

GET /car/new/ -> form for creating a new car 
POST /car/new/ -> redirect to /car/<id>/ if item is created else show form with invalid fields highlighted 

ale według http://www.slideshare.net/Wombert/phpjp-urls-rest to nie jest dobry REST URL. Rozumiem, dlaczego nie jest to dobry REST, ponieważ "nowy" jest naprawdę używany jako czasownik, a nie jako zasób, ale gdzie powinien być ten formularz, ponieważ GET /car/ jest już używany do wyświetlania samochodów, więc nie można użyć GET /car/ dla formularz dla nowych samochodów.

W skrócie, moje pytanie brzmi: "Jaki jest URL" RESTful "dla" tworzenia formularza zasobów "?"

W przypadku nieco pokrewnych informacji, nawet w usługach internetowych, czasami nie zawsze mądrze jest polegać na kliencie znającym schemat z wyprzedzeniem, dlatego nawet w usługach internetowych może istnieć potrzeba bycia sposobem dla klienta. zażądaj bieżącego schematu zasobu. AFAICS, jest to podobna sytuacja z koniecznością pobrania formularza tworzenia (tj. Formularz jest podobny do schematu opisującego sposób konstruowania zapytania POST do tworzenia zasobu). Czy moja linia myślenia jest tutaj poprawna?

Answer 1

REST nie przejmuje się zbytnio tym, jak wygląda Twój identyfikator URI, o ile identyfikuje jeden unikalny zasób i samoopisuje. Spełniaj te kryteria, a poza tym są to osobiste preferencje. Nic nie zabrania używania czasownika w URI, jeśli ma sens korzystanie z niego.

W odniesieniu do nieznacznie powiązanej notatki, wskazówka dotycząca formularza będącego schematem to: typ nośnika. Architektura RESTful dotyczy zarówno klienta, jak i serwera, obaj rozumieją typy mediów używane do reprezentowania stanu aplikacji.

odpocząć API powinien wydać prawie wszystkie jego opisowy wysiłku w określające typ (y) multimedialny używany do reprezentowania zasobów i jazda stanu aplikacji, lub w definiowaniu rozszerzonych nazw zależność i/lub znak hipertekstu z obsługą -up dla istniejących standardowych typów mediów. Dowolny wysiłek wydany przez firmę poświęcono opisywaniu, które metody, które należy zastosować w przypadku interesujących identyfikatorów URI , powinny być w pełni zdefiniowane w zakresie reguł przetwarzania dla rodzaju nośnika (oraz, w większości przypadków, już zdefiniowanego przez istniejące typy nośników ).

Czytaj więcej tutaj: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

To Roy Fielding, człowieka, który zdefiniowany resztę. Ogólnie rzecz biorąc, typy multimediów powinny być rozszerzalne - to znaczy, że wszelkie zmiany powinny dodawać, a nie łamać starszych klientów, chyba że jest to konieczne.

Answer 2

Zawsze zakładałem, że "forma" jako taka nie jest zasobem, więc /<name>/new jest w porządku - formularze nie są zwykłymi elementami API. Autor slajdów umieścił to na "złej" liście, ale nie dostarczył poprawnej - zakładam, że był tak ZNIEKSZTAŁCONY, że zapomniał o takich przypadkach pomyśleć.