/users/<id>/posts [GET]: Get all posts for the specified user
The first thing that I notice is that we would expect the representation of this resource to change when a new post is added. Therefore, I would normally want the HTTP request that causes this resource to change to reference the same target URI, so that we can take advantage of general-purpose cache invalidation.
Therefore, I would argue for
The key idea here being that the URI we use is the same - the actual spelling of the URI doesn't matter very much. The same principle would hold for
If caching isn't important to you, then you can reasonably design your interface so that read and write use different resource identifiers. I'd expect a PR that makes another choice to include a decision record (see Nygard 2011, or Kruchten 2009) describing the analysis done to understand the tradeoff balance.
Looking at Laiv's answer, I'm reminded that I should probably be more clear about the mechanism I'm suggesting.
Assuming that the server wants to announce the creation of a new resource, and that the server is going to choose the identifier of the new resource, the interaction would look like:
General purpose HTTP components aren't going to care what spelling conventions are used in the URI of the new resource. So
/users/123/posts/6789 would be fine, as would
/91ca7e41-8298-450d-8d8f-9327f8d64867. It's an opaque identifier.
(Which isn't to say that it doesn't matter - humans will want identifiers that are sensible, in much the same way that we want variable names to be sensible.)
If all you are really doing is modifying a single resource (ie: posts aren't represented by individual resources, but instead are data embedded within the /user//posts resource), then we certainly want to be using /user//posts as the target URI, because (again) that's the important document we are changing, and general purpose caches will know what to do.