I\'m trying to move a resource from /buckets/1
to /buckets/2
such that:
Create original resource:
PUT /bucket/1
Call server procedure that responsible for moving resources:
POST /bucket/1/move-to/2
Original resource path now should return Moved status code:
GET /bucket/1 HTTP 301
Resource now should be available on new path:
GET /bucket/2 HTTP 200
GET /buckets/1
DELETE /buckets/1
PUT /buckets/2 {data returned by #1}
That doesn't make the server 301
, though. The alternative would be to use the WebDAV MOVE method, i.e. by creating your own @MOVE
annotation using the @HttpMethod
annotation:
import ...;
@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@HttpMethod("MOVE")
public @interface MOVE {}
but doing so breaks REST's architectural principle of using HTTP as a uniform interface (RESTful Java).
Answering my own question:
/balls
GET /buckets/1
returning the value of the ball in the bucket let's have it return the URI of the ball instead.We can then move balls as follows:
(examine original state)
GET /buckets/1: "balls = {'/balls/1'}"
GET /buckets/2: "balls = {}"
GET /balls/1: "bucket = /buckets/1"
(move ball into bucket #2)
PUT /balls/1: "bucket = /buckets/2"
(examine new state)
GET /buckets/1: "balls = {}"
GET /buckets/2: "balls = {'/balls/1'}"
GET /balls/1: "bucket = /buckets/2"
End-result: the ball's identity remains consistent as it moves across buckets and (most importantly) this operation is atomic.