Reprezentuj działania (czasowniki) w URI REST

Mam operację drukowania do wykonania dla dokumentów klienta. Potrzebuję też innych standardowych operacji, takich jak dodawanie, aktualizowanie, usuwanie. więc mam następujące:

• Do tworzenia nowego klienta:
  URI = / customer / {id}, wpisz = POST, Methodname = CreateCustomer ()
• Do aktualizacji:
  URI: / customer / {id}, wpisz = PUT, method = UpdateCstomer ()
• W przypadku opcji Usuń klienta:
  URI = / customer / {id}, wpisz = DELETE, Methodname = DeleteCustomer ()
• W przypadku widoku:
  URI: / customer / {id}, wpisz = GET, method = GetCustomer ()

Teraz, jeśli muszę wydrukować dokument dla tego klienta, potrzebuję funkcji drukowania. Mój identyfikator URI może wyglądać następująco: / customer / {id}, type = POST, method = PrintCustomer (). Ale użyłem tego typu URI i POST dla CreateCustomer. Chciałem, aby identyfikator URI wyglądał tak: / customer / Print / {id}, type = POST, method = PrintCustomer ().

Ale nie mogę mieć czasownika „Drukuj” w moim URI. Jak najlepiej to zrobić? Myślałem o / customer / document / {id} jako URI ... ale napotkam ten sam problem. Chciałbym mieć operacje CRUD na „dokumencie”. Więc znów zabrakło mi tego, co chciałbym użyć do „drukowania”. Proszę doradź.

POSTnie oznacza „stwórz”, oznacza „proces”. Możesz utworzyć nowy zasób, wysyłając odpowiednie żądanie do istniejącego zasobu (tj. Opublikuj, /customersaby utworzyć nowego klienta). Ale możesz także użyć POSTdo wypełnienia wszystkich innych akcji, które nie odpowiadają zgrabnemu paradygmatowi CRUD.

W przypadku drukowania powinieneś rozważyć akt drukowania jako sam zasób. Poprosisz system o utworzenie dla ciebie „zadania drukowania”. Oznacza to, że możesz mieć prints/zasób, który będzie pojemnikiem dla wszystkich żądanych wydruków. Jeśli chcesz wydrukować coś, POSTto dokument do tego zasobu, który zawiera wszystkie informacje o wydruku, który chcesz utworzyć, identyfikując zasoby, które chcesz wydrukować, z linkami do nich.

Jako dokument JSON mógłby wyglądać następująco:

{
   contents: ["http://site/customers/12345"],
   paper-size: "A4",
   duplex: "true"
}

Oczywiście musisz to dostosować, aby odpowiadało temu, co chcesz zrobić. Najważniejsze jest to, że identyfikujesz inne zasoby do wydrukowania, podając ich adres URL.

W odpowiedzi na prośbę możesz po prostu zwrócić a 200 OKlub a 204 No-Contenti potraktować to jako proces typu „odpal i zapomnij”. Jeśli jednak chcesz go ulepszyć, możesz zwrócić 201 Createdi podać adres URL nowo utworzonego zadania drukowania, np /prints/12345.

Użytkownik może następnie wykonać GETna zasobie, aby zobaczyć status swojego zadania drukowania (w toku, w toku, itp.), Lub może poprosić o anulowanie zadania przez wydanie polecenia DELETE.

Po ponownym sformułowaniu problemu dotyczącego zasobów projekt RESTful powinien pojawić się w sposób naturalny i dać możliwość rozszerzenia i ulepszenia w sposób, który mógł nie być od razu rozważany.

Zrobiłem to wcześniej. Aby wydrukować dokument, zwracam tylko wersję pdf zasobu. Klient musi jedynie wysłać żądanie GET dla zasobu za pomocą polecenia Akceptuj nagłówek / pdf.

Pozwala to również uniknąć tworzenia nowego identyfikatora URI dla zasobu tymczasowego, takiego jak zadanie drukowania. Użycie nagłówka HTTP jest również częścią REST i utrzymuje URI w czystości.

Wystarczy dodać parametr do GET bieżącego identyfikatora URI

Używanie identyfikatora URI do wielu działań jest dość typowe.

Jeśli mówisz o tym samym zasobie, ale o innej akcji, zdefiniuj go jako parametr.

/ customer / {id}? print = true

Następnie, gdy definiujesz metodę GET, wykrywasz obecność parametru drukowania i postępujesz inaczej.

REST jest definiowany w następujący sposób:

• POST - Utwórz rekord, zasób lub zasób
• PUT - aktualizacja, rekord, zasób lub zasób
• USUŃ - Usuń rekord, zasób lub zasób

Z drugiej strony GET ma być wykorzystywany na wiele sposobów, ponieważ zwykle istnieje wiele różnych form, z których można odzyskać zasób. Dlatego też żądania GET są reprezentowane jako ciąg zapytania. Jeśli pracujesz z zasobem bazy danych, dosłownie pobierasz widok za pomocą zapytania, ale REST jest celowo wyodrębniany na wyższy poziom, ponieważ jest zaprojektowany do obsługi wielu różnych rodzajów zasobów.

Specyfikacja REST jest dość przyszłościowa, mimo że interfejsy API dopiero niedawno zaczęły ją intensywnie wykorzystywać.

Jeśli chcesz dowiedzieć się więcej o protokołach REST, gorąco polecam przeczytanie „ Haters Gonna Hate HATEOAS ”.

Aktualizacja:

@Shauna wskazał na interesującą dziurę w moim rozumowaniu. Nie ma prawdziwe właściwa droga i wiele form są uważane za dopuszczalne. Zastanowiłem się nad tym trochę, a ponieważ zamierzonym zastosowaniem jest przekształcenie danych w inną reprezentację, sensowne jest zdefiniowanie transformacji jako nowego typu MIME.

Na przykład możesz reprezentować identyfikator URI jako:

/customer/{id}+print

Gdzie można ustawić odpowiedź Content-Type na text / html + print. W ten sposób będziesz mieć również możliwość zdefiniowania większej liczby transformacji w przyszłości.

Na przykład:

// for application/json
/customer/{id}+json

// for application/atom+xml
/customer/{id}+atom

Tak czy inaczej, wszystkie formy są dopuszczalne. Implementacja, którą wybierzesz, zależy bardziej od osobistych preferencji i możliwości twojego serwera.

Na bok: Pozwól, że wyjaśnię, ponieważ wydaje się, że istnieje pewne zamieszanie. Parametr zapytania „print” i / lub typ zawartości służy do określenia sposobu transformacji zasobu. Nie jak uruchomić fizyczne zadanie drukowania. Ze względów bezpieczeństwa dostęp na poziomie sprzętowym jest zawsze pozostawiony użytkownikowi / klientowi / przeglądarce.