REST resource related data

I've created a REST API and I think I'm stuck with a RESTful issue.

It's related with the following questions:

I have a resource called "cases". Cases have also related data, like users and messages. The problem is that I want to get the related queried users and messages data from a case, but I'm not sure with the URI design. There are also different kinds of related/calculated data. These related data should be used to create data visualization.

How I get cases/users/messages are RESTful though:

http://example.com/cases (and with id for a single case)
http://example.com/cases/{id}/users (same idea as above)
http://example.com/cases/{id}/messages (same idea as above)

My first thoughts to create related resources are (I think URI looks wrong, it's maybe getting a bit RPC?):

Related data 1:

http://example.com/cases/{id}/analysis/messages-network-traffic

{
    "sender": "an user jack", 
    "receiver": "an user steph", 
    "amount_messages": 51
}, 
{
    "sender": "an user test", 
    "receiver": "an user test4", 
    "amount_messages": 3
}
...

Related data 2:

http://example.com/cases/{id}/analysis/messages-timeline?receiver=testuser1&sender=testuser2
{
    "amount_messages": 24, 
    "timestamp": 1387321576
}, 
{
    "amount_messages": 50, 
    "timestamp": 1387321576
}
...

Are these correct thinking of URI design (I think it's kind of RPC though), or how should I do? Because I don't see any reason to CREATE a report resource like the related questions. The data is just a calculation of the existing resources.

Thank you in advance.

Solution

Just because you can provide an implementation doesn't mean it makes sense to do so. For example, performing a PUT on http://example.com/cases probably doesn't make sense. You would PUT instead to http://example.com/cases/1 or something like that. A specific instance. Likewise, performing a POST on http://example.com/cases/1 probably doesn't make sense either. It is up to you to decide the semantics of your application, using the syntax of REST.

I don't see anything wrong with your REST design- As long as the endpoints are named in a 'declarative' fashion, then it is OK. If they had some 'procedural' name, like: http://example.com/cases/goDoSomething, that would be a cause for concern.

Remember your REST design is the "language" your clients use to talk to your services, so design that language so that communication is declarative and suited for the task at hand. Design for the USERS, not for your own convenience in the backend.