Side effects on other resources
rest
Solution
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.
Problem
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.