I don't exactly understand your specific example, but I'll still try to give my advice.
REST is all about entities, or state, and state transitions. It kinda seems like what you want to do is query for some state. Let's look at the common HTTP verbs:
- Commonly used for creating additional state on the server.
- Commonly used for creating or updating existing state on the server.
- Used for deleting some state from the server.
The above methods don't make sense for checking existing state, which you want to do. I've left out CONNECT, TRACE, and OPTIONS, since those also don't seem to be appropriate here.
- Used for getting state from the server.
- Same as GET but only returns the metadata.
So it seems like GET or HEAD may be most appropriate, depending on where you are returning the information (in the metadata or entity/body). Since you are not transferring state to the server, but querying it, perhaps it should be the responsibility of the client making the assertion to do that instead of the server doing assertions.
If you want to take advantage of HTTP error codes, perhaps you could add a query parameter. For example HEAD posts?min_posts=5 could return 404 (Not Found) if there are no posts meeting that requirement. Otherwise it could return 204 (No Content) if it met the requirement.
If you don't want to use GET or HEAD, you could try using POST, but that requires you to create some entity representing the state that you are POSTing, ex. an "assertion" entity. It could return 409 (Conflict) if the assertion fails, since the state of the resource in the request (i.e. the assertion) has a conflict (i.e. is not true or did not pass). If the assertion passes, you could return 204 (No Content). This approach kinda seems like a hack to me, though. But it may actually make sense, depending on the details of your system.
I also want to add that a "REST" API is rarely implemented correctly. Sometimes due to acceptable/practical tradeoffs from the REST guidelines. Other times due to ignorance of what REST means.