PUT-Methode (RESTful) funktioniert nicht als eine Möglichkeit zur Aktualisierung von Ressourcen

Die Idee, die hinter "HTTP-Verben" wie PUT, GET, POST, DELETE sind nur eine Frage der Protokoll-Semantik. Nur die Durchführung einer HTTP-PUT-Vorgang nicht tun, etwas Magisches. Es ist nur die richtige Semantik wir als Entwickler sollten verstehen, während der Entwicklung, als diese Semantik allen bekannt (das ist, warum existieren Protokolle). Wenn niemand folgte dieser Semantik, dann wäre die Welt irgendwo zwischen der Großen Depression und der Apokalypse.

Dass gesagt wird, diese Verben (Semantik) sind eine Art von Garantie (oder vielleicht auch die Qualitätssicherung ist ein besseres Wort) an den client, der die Anforderung durchführt, die mit einem bestimmten verb haben einige wissen-Semantik um es. Ein wesentlicher Faktor ist die Idee, idempotenz. Idempotenz ist die Idee, dass, egal wie viele Male ich einen Antrag stellen, das Ergebnis wird das selbe (oder die gleiche Wirkung haben).

Bestimmte HTTP-Verben sind, sagte idempotent, wie PUT, DELETE, GET. Egal wie oft machen die genau die gleiche Anfrage, die Allgemeine Idee ist, dass das Ergebnis/Effekt sollte der gleiche sein. POST auf der anderen Seite wird gesagt, um nicht werden idempotent, als der exakt gleiche POST-Anforderung können unterschiedliche Ergebnisse erzeugen, beispielsweise eine Bestellung aufzugeben, zu Unrecht, erneut, oder erstellen Sie eine neue Kunden-doppelt.

Wenn wir wollen, um die Welt zu einem besseren Ort, und tragen unseren Teil bei der Rettung der Welt von einer kompletten Kernschmelze, sollten wir lernen, diese Semantik und gute Bürger sein, indem Sie Ihnen zu Folgen. Es gibt eine Menge mehr zu lernen, über die verb-Semantik, als nur idempotenz, aber verstehen, dass viel, ist ein guter Anfang. Ich würde vorschlagen, vielleicht picking up ein gutes Buch in RUHE zu lernen, einige gute Praktiken. Oder wenn Sie wollen, Sie wollen ein Kind, nehmen Sie sich Zeit, die Bibel zu Lesen (eigentlich die Fielding Dissertation).

Alle, dass gesagt wird, es ist unsere job als Entwickler code zu erstellen der Folgen dieser Semantik. Der Grund, Ihre Methode ist das erstellen einer neuen Ressource, ist wahrscheinlich, weil Sie sind erstellen Sie eine neue Ressource mit dem code. Vielleicht so etwas wie dieses würde scheinen besser geeignet:

@PUT
@Path("/customers/{id}")
@Consumes(MediaType.APPLICATION_JSON)
public Response updateCustomer(@PathParam("id") long id, 
                               Customer updateCustomer) {

    Customer customer = customerService.getCustomerById(id);
    if (customer == null) {
        throw new WebApplicationException("Can't find it", 404);
    }

    customer.setFirstName(updateCustomer.getFirstName());
    customer.setLastName(updateCustomer.getLastName());
    ...

    return Response.noContent().build();
}

Also sind wir nur aktualisieren Sie die Kunden, die bereits in unserer Datenbank. Normalerweise mit einer PUT-Anfrage zu aktualisieren, die insbesondere Kunden Ressourcen-URI bekannt sein sollte. So sagen die client stellt eine Anfrage an http://blah.com/api/customers/1234 unser service wird den Kunden mit der id 1234. Wenn es nicht gefunden werden kann, kehren wir ein 404 status-code, da die Ressource nicht existiert. Wenn es vorhanden ist, dann aktualisieren wir den Kunden mit dem Kunden zur Verfügung gestellten Daten in die Anfrage. Wenn Sie wollten, um einen neuen Kunden erstellen, wo die URI ist nicht bekannt, dann POSTEN wäre korrekt, und Sie würde senden Sie eine Kunden-Vertretung http://blah.com/api/customers.

Halten auch nur ein FYI: in vielen Fällen, in einem Fall wie diesem, was passiert ist, dass die client-Anfragen (GET) eine Ressource, sagen Sie einem Kunden, und updates, die von Kunden Darstellung, dann schicken Sie es zurück, wie PUT-Anfrage mit dem Kunden aktualisiert. Auf dem sever werden soll, dass die Informationen zu aktualisieren, die insbesondere die Daten seiner Kunden, wie Sie sehen können aus dem Beispiel oben.

UPDATE

Pro Ihre Bearbeiten. Sie sind völlig fehlt der Punkt, wie das funktionieren soll.

Customer cust = new Customer();
cust.setName("After");
cust.setPostcode(222);

target.path("Before").request().put(Entity.xml(cust));

Was falsch mit diesem ist, dass mit dem neuen Customer bestimmen Sie die Kennung "After", die sich von der Kennung in der Anforderung Weg, Sie sind mit "Before". Also die path-variable {id} ist "Vor". Mit diesem request-URI Sie sagen, dass Sie möchten, um Zugriff auf die Kunden-id "Vor". Wie in meinem code, es ist Ihre Pflicht zu prüfen, ob ein Kunde mit der id "Vor" in der Datenbank vorhanden. Wenn nicht, sollten Sie Sie wieder zurück 404 Not Found. Die name (id), die Sie für die neue Customer sollte die id dürfte in der Datenbank. Also, wenn Sie aktualisieren möchten den Kunden mit der id in der Datenbank "Nach". dann sollten Sie "Nach" in den Pfad statt "Vor". Wir sollten nicht versuchen, und ändern Sie die id.

Wie ich schon sagte, wenn wir möchten, aktualisieren Sie eine Ressource, die wir normalerweise, BEKOMMEN die Ressource, Aktualisierung einiger Felder (aber nicht die id), und senden Sie es zurück. Eine Sequenz könnte so Aussehen

final String PATH = "http://hello.com/api/customers"
WebTarget target = client.target(PATH);
Customer customer = target.path("1234").request().get(Customer.class);
//where 1234 is the id (or in your case `name` of the customer.
//I would avoid using the name as the DB id, that's why my example uses numbers
customer.setPostalCode(...);
target = client.target(PATH).path(customer.getName()); //getName should be 1234
Response response = target.request().put(Entity.xml(customer));

Wir verwenden die gleiche id, wie uns zur Verfügung gestellt wurden, in den Weg, denn das ist, wie die Ressource identifiziert, die in der server.