考虑REST幂等性，Car的PUT接口是否需接收不可编辑参数？

Great question—this cuts to a common conflict between strict REST principles and real-world API usability, especially when dealing with immutable fields and PUT's idempotency guarantee. Let's break this down based on your Car resource scenario:

1. Strict REST Semantics: Require All Fields (Including Immutable Ones) #

By the book, PUT is designed to replace the entire state of a resource. That means the client should send a complete representation of the Car (including vinNumber and retailerId) every time they make a PUT request. Here's how this plays out:

• Idempotency is guaranteed: If you send the same full resource representation 10 times, the server will overwrite the Car with that exact state each time—no unexpected changes, no side effects.
• Error prevention: If the client accidentally sends a different vinNumber than the existing one, the server can reject the request with a 400 Bad Request (since that field is immutable). This catches mistakes early and keeps data consistent.
• Tradeoff: The client has to store the full resource state from a prior GET request, which adds a bit of overhead. They also have to include redundant fields in every PUT, which feels unnecessary for immutable values.

2. Practical API Design: Allow Only Editable Fields #

In many real-world APIs, teams relax the strict REST rule to make things easier for clients. Here, you'd let the client send only the editable fields (name and age) in the PUT request, and the server retains the existing values for vinNumber and retailerId.

• Idempotency still holds: Sending the same name and age multiple times will always set those fields to the same values—no matter how many times you run the request, the final state of the Car is identical.
• Usability win: Clients don't have to track or send fields they can't change, which simplifies their code.
• Catch: This blurs the line between PUT (full resource replacement) and PATCH (partial update). Purists might argue this isn't "true" REST, but it's a widely accepted pattern because it solves real pain points.

3. Handling Immutable Fields If They Are Sent #

Whichever approach you pick, decide how to handle it if a client does send an immutable field in the PUT request:

• Strict validation: Reject the request with an error if vinNumber or retailerId doesn't match the existing value (or if it's provided at all when it shouldn't be). This enforces immutability explicitly.
• Silent ignore: Just drop the immutable fields from the request and use the existing values stored on the server. This is more forgiving but might hide accidental client mistakes.

Final Recommendation #

There's no one-size-fits-all answer, but here's what I'd suggest:

• If you want to stay strictly aligned with REST principles, require the full resource representation and validate immutable fields.
• If usability is your top priority, allow only editable fields in PUT requests, but document clearly that this is a pragmatic deviation from strict REST (and maybe consider using PATCH instead if your API can support it, since PATCH is intended for partial updates).

Either way, as long as multiple identical PUT requests leave the Car resource in the same state, you're honoring the idempotency requirement of REST.

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