REST中POST提交已有记录的结果及PUT与POST的区别与适用场景

Great question—let’s unpack this clearly, starting with your specific scenario, then diving into core differences and real-world use cases.

Your Specific POST Request Scenario #

You have an existing User record: Id=1, name="Pritam", and you send a POST request with the same Id=1, name="Pritam" body. Will this create a duplicate?

The short answer: It depends on how your backend is implemented, but here’s what’s typical:

• By REST design principles, POST is intended for creating new resources, usually targeting a collection endpoint (like /users). If your backend doesn’t enforce uniqueness on the Id field, it might create a duplicate entry (even with the same Id, unless Id is a database auto-increment primary key—then you’d likely get an error like 409 Conflict or a database constraint violation).
• If your backend checks for existing Id values before processing POST requests, it might return an error (e.g., 409 Conflict) indicating the resource already exists instead of creating a duplicate.

The key point here: POST doesn’t inherently prevent duplicates or enforce idempotency—that’s up to your application logic.

Core Differences Between PUT and POST #

Let’s break down the critical distinctions that matter for development:

• Semantic Purpose
  • POST: Creates a new, server-assigned resource. You send data to a collection endpoint (e.g., /users), and the server generates a unique URI for the new resource (like /users/2) in response.
  • PUT: Updates an existing, client-specified resource (at a known URI like /users/1). If the resource doesn’t exist, PUT will create it at that exact URI (this is optional but common in implementations).
• Idempotency
  • PUT is idempotent: Sending the same PUT request 10 times will have the same result as sending it once (the resource at /users/1 will be updated to the request body’s state, no duplicates created).
  • POST is non-idempotent: Sending the same POST request multiple times will create multiple resources (unless your backend adds safeguards).
• URI Target
  • POST targets a resource collection (e.g., /users), not a specific resource.
  • PUT targets a specific resource directly (e.g., /users/1).
• Request Body Expectation
  • PUT expects the full representation of the resource (you should send all fields, even unchanged ones, to fully replace the existing state).
  • POST can accept partial data or just the necessary fields to trigger resource creation (since the server is responsible for generating the full resource state).

Practical Use Cases #

When to Use POST #

• Creating resources where the server controls the URI (e.g., submitting a form to create a new user, where the server generates the user’s unique ID).
• Executing non-idempotent actions (e.g., submitting an order, sending a password reset email—each request triggers a unique action that shouldn’t be repeated).
• Triggering side effects that don’t map to a single resource (e.g., running a batch job, logging an event).

When to Use PUT #

• Updating a full resource at a known URI (e.g., editing all details of a user with Id=1 by sending the complete user object to /users/1).
• Creating a resource where you define the URI upfront (e.g., uploading a profile photo to /users/1/avatar—you know exactly where the resource should live).
• Performing idempotent actions (e.g., resetting a user’s password to a specific value—sending the request multiple times won’t change the outcome after the first time).

内容的提问来源于stack exchange，提问作者Pritam