CODEWITHSUNDEEP
apirest
Lorenzo Felletti
Lorenzo Felletti

Reputation: 563

Rest API resources: composed for post but separate to get is ok?

I'm creating a set of RESTful API and I have this question: I have a resource that has some images attached and I'm creating my resources like this: POST to /resource: create the object and save the images to the server. GET to /resource returns the object but no the images, GET to /images returns the images. My question is: is this compliant with REST or should I either make the resources completely separate or completely unified? I choose this solution because when posting I for sure send the images, but I may need them or not when doing a get.

Upvotes: 0

Views: 395

Answers (2)

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57387

is this compliant with REST

It's fine - for instance, if you look at the way that Atom Publishing works, you'll see that when you post a media to a collection, two resources are created (the Media Resource and the Media Link Entry).

However, fine here means you are making tradeoffs. In particular, cache invalidation is more challenging when you a POST to one resource may change the representation of a different resource.

HTTP caching semantics are optimized for the common case, which is that a given request changes only the target resource; no spooky action at a distance.

That doesn't mean that this is the Right Way, but rather that you should understand that this is the way that HTTP makes easy, and in other cases you need to pay attention to the details.

Upvotes: 1

Evert
Evert

Reputation: 99841

POST can basically mean anything, and unlike PUT and GET (for which there is a bit more of a direct relation), POST is allowed to result in all kinds of side-effects, including the creation of 0 or more resources.

POST is basically the 'anything goes' method.

Upvotes: 1

Related Questions