Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 1 down vote favorite

As title: Why is aggregation function bad idea for RESTful? Although I know CRUD is good for RESTful.

For example, the resource is 'employee', and client needs to retrive sum of total 'salary' of all employees. Shouldn't RESTful service provide such sum function?

Further question: if aggregation function is bad for RESTful, how can a client get sum of total salary? To retrieve all 'employee' records and sum up itself?

share|improve this question
See my answer here programmers.stackexchange.com/questions/204458/… In short, functions shouldn't exist in REST. Create a SOAP service in which you pass in the resource ids, etc. – Andrew Finnell Jul 17 at 12:42
1  
I just created a new term... REST-RPC. And as the creator, I hereby declare that if you want to pull back aggregate data or trigger actions on a server using a simple http request rather than getting into the muck that is SOAP, you are approved, and are still properly adhering to REST-RPC principles. I also declare that peanut M&M's are the best kind of M&M's. – GrandmasterB Jul 17 at 21:45
add comment (requires an account with 50 reputation)

2 Answers

up vote -1 down vote

Because it tries to force a service specific verb into an architecture whose limited list of standard verbs is one of its big advantages.

Almost always when you are trying to force a verb (average, transfer, ...) on a REST interface, there is a hidden resource lurking somewhere.

To get into a better REST style stop the verb thinking that comes from RPC (Remote procedure call) and start thinking resources. The aggregations you are talking about in REST are better exposed as attributes of a department and/or manager and/or company resource.

I strongly recommend reading RESTful web services. I think you will find the information about the differences between REST and RPC as well as all the information about resource and URI discovery very useful.

How can a client get sum of total salary?

The sum total of salaries for whom? The company? A department? A manager that is involved with two departments? Wouldn't the company, the department or the managers be resources in their own right? Each with a number of employees "under" them?

Giving the client access to the list of employees for these resources could be one way of allowing them to sum the salaries themselves. But that could pose all kinds of privacy and authorization issues. So maybe it would be better if the company, department and manager resources simply provided a "total_salary" attribute that would be calculated by the service.

share|improve this answer
Projection and aggregation have nothing to do with RPC. It's is something that greatly enhances any queryable system and if done on the server side can greatly help reduce resource consumption. And yes, total salary is something that could belong to a department. But what if I want the average salaries depending on age group, sex, academic level. Should that be a property of the department? And the company? And every section? – back2dos Jul 17 at 18:19
@back2dos: nope, not necessarily. However, the flexibility you are seeking is not something that is solved by verbs either. The resource you are looking for is the payroll with a number of attributes and several query parameters in what the "RESTful web services" book calls algorithmic resources. /payroll/salaries/average/female/40;45/masters/ comes to mind. Or if you want /payroll/salaries/average?sex=female&agegroup=40-45&academiclevel=masters. Still no need for verbs! – Marjan Venema Jul 17 at 19:01
Ok, so rather than having a verb, I have nouns that represent an action? How is that better? In fact I would claim that such a system has significantly worse discoverability. What if I want the average ages per position type? Or the number of employees for each initial letter? SQL can do it, most document stores can do it. And all without having to add any further pseudo-entities to the domain model, just because somebody may need them. It's not uncommon to allow specifying return fields and even their format in "RESTful" APIs. Adding aggregation on top of that is only the next logical step. – back2dos Jul 17 at 20:14
@back2dos: No, you don't have nouns that represent actions. You have nouns and collections of noun things. You create, read, update and delete those nouns. If you want to link two nouns, you don't LINK them but you CREATE a "whatever" noun that links them. If you want a specific collection of nouns, you GET it telling the service which nouns you want and what criteria they need to meet. You then let the service worry about how to get you those. REST takes a mind shift to get. Please go read up on it. There are authors out there that are way better at explaining what REST is about than I am. – Marjan Venema Jul 17 at 21:00
Discoverability in REST is addressed by including links to other resources in almost every resource. Links can tell a client what other resources can be gotten, created, updated or deleted (previous/next page, sub lists, parents, POSTing a new child, whatever). Links are also a perfect way to avoid application state by transforming application state to links included in/added to every resource See Hypermedia As The Engine Of Application State – Marjan Venema Jul 17 at 21:07
show 2 more commentsadd comment (requires an account with 50 reputation)
up vote -2 down vote

I know CRUD is good for RESTful.

Wrong, CRUD is very far from REST; typically separated at least by 2-3 layers of abstraction.

The point is: REST doesn't deal with database records, it handles resource representations.

Now, what's a resource? is it a database record? no, it's not. It's a more extensive, abstract concept. Resources in a system can be User profiles, activities, documents, statistics, etc.

In your example, you have an employee resource, I guess there's also a division resource, which can list the related employees. Maybe also an enterprise resource, which contains divisions. But there could also be a middle managers resource, with employees from all divisions.

Any of these "grouping" resources should have a link to the list of "contained" resources, and also some other attributes, like full name, a longer description, maybe an address, etc. Also there could be links to other "complementary" resources, like a webpage, a document repository, etc. Among those, there could be a "statistics" resource, with all the aggregations you want, either as prespecified fields, or via some specifications in the URI.

share|improve this answer
2  
You seem to have inferred that CRUD somehow meant database. REST is accessed through the HTTP CRUD verbs GET, Post, put and delete. – Andrew Finnell Jul 17 at 14:40
3  
from wikipedia "create, read, update and delete are the four basic functions of persistent storage." So, yes, CRUD is the database. Get, post, put and delete do not simply create records, they handle representations. (which can be made to correspond 1:1 with records, but that's just one limited use) – Javier Jul 17 at 14:42
2  
@Javier CRUD is a concept, not directly tied to databases, which contains the verbs READ, CREATE, DELETE, UPDATE. Databases implement it with the verbs SELECT, INSERT, DELETE, and UPDATE. REST implements it with the verbs GET, POST, DELETE, PUT. They are not separate concepts, but closely interrelated. – Izkata Jul 17 at 16:06
"Persistent storage" does not necessarily mean 'database'. It could be a file-store, or any other mechanism to persist resources. – Eric King Jul 17 at 16:20
@EricKing. right, any mechanism to persist records, but resources, as defined for REST, are other thing, not necesarily persistent records (ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm, part 5.2.1.1) – Javier Jul 17 at 17:13
show 1 more commentadd comment (requires an account with 50 reputation)

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.