Side effects on other resources

Question

This is a theory / best practices question regarding RESTful and HATEOAS design...

Given the resources:

/myresources/ (a collection of our resource objects)

and

/transactions/ (a collection of historical transactions that have occurred in the system)

Is it a valid practice for:

POST /myresources/

to not only create a new resource at /myresources/ but also a new resource at /transactions/?

In other words, can a POST (or any verb) to one URL effect resources at both that URL and others? Is there another approach? Obviously we could use two POSTs, but that requires us to trust the user to maintain valid state across multi-resource modifications.

Answer 1

Yes, this is fine. Imagine another case where the system exposes a /myresources/latest URI. When there are no resources, that might return 404, but when you start POSTing resources, both the canonical URI and the latest URI will return 200 OK. There are many, many useful benefits to this approach.

However, keep caching in mind while you design such resources. If you POST to the /myresources/ collection, for example, you will invalidate that collection in any caches along the way. You will not, however, invalidate the /transactions/ collection, and the two indices could get out of sync. They can be out of sync across the whole system anyway, depending on the graph of caches in between multiple clients and the origin server(s), but often, clients get designed to expect this action at a distance to be synchronous, and caching can frustrate that in cases like this.

Answer 2

It seems entirely reasonable to me. There is no way the person creating the new resource could tell if, for example, this was implemented by having another client poll for new resources, then inject the transaction resource, right?

So, there isn't any conceptual issue at that level, let alone the "is it reasonable for the server to create new resources" level.