// Nie praktykuje się tego zbyt często, ale można zdefiniować dedykowane metody dające dostęp do poszczególnych pól obiektu (aby nie transferować całego rekordu, gdy potrzebna tylko jedna informacja)
// Nie praktykuje się tego zbyt często, ale można zdefiniować dedykowane metody dające dostęp do poszczególnych pól obiektu (aby nie transferować całego rekordu, gdy potrzebna tylko jedna informacja)
...
@@ -77,6 +98,10 @@ public class RProducts {
...
@@ -77,6 +98,10 @@ public class RProducts {
returnoneProduct(productId).getPrice();
returnoneProduct(productId).getPrice();
}
}
// Operacja HTTP PUT zapisuje zasób pod podanym adresem.
// W zapytaniach typu PUT i POST klient wysyła dane na serwer (treść zapytania: "body" / "entity" / "content" ...)
// W JAX-RS metoda może posiadać tylko jeden parametr bez adnotacji i to właśnie przez ten parametr przekazywana jest treść zapytania
// (te dane, które przysłał klient). Format tych danych opisuje adnotacja @Consumes
@PUT
@PUT
@Path("/{id}/price")
@Path("/{id}/price")
@Consumes({"application/json","text/plain"})
@Consumes({"application/json","text/plain"})
...
@@ -90,6 +115,30 @@ public class RProducts {
...
@@ -90,6 +115,30 @@ public class RProducts {
}
}
}
}
// PUT vs POST
// PUT powinniśmy używać wtedy, gdy z góry wiadomo, pod jakim adresem zostaną zapisane dane.
// W praktyce PUT używa się najczęściej do aktualizacji istniejących danych, ale teoretycznie PUT
// można też użyć do zapisania nowych danych pod konkretnym adresem.
// Gdy wyślemy dane za pomocą PUT pod adres, to następnie GET z tego samego adresu powinien odczytać dane, które wysłał PUT (być może w innym formacie).
// POST używajmy wtedy, gdy nie wiemy z góry pod jakim adresem dane zostaną zapisane, np. gdy id rekordu jest generowane z sekwencji.
// Taka metoda powinna dać w odpowiedzi informację o ID utworzonego rekordu.
// Kilka możliwości:
// 1) odesłanie uzupełnionego rekordu - trochę niewydajne, ale wygodne
// 2) minimalny dokumencik JSON, w którego wnętrzu jest zawarta ta informacja (tak robi wiele usług w praktyce, np. PayU)
// 3) (teraz w tej wersji) - odesłać odpowiedź typu Created z nagłówkiem Location - najlepsze z punktu widzenia standardów/dobrych praktyk
// Aby zwracać taie "techniczne" odpowiedzi, używa się klasy Response.