Lumping vs. Splitting (REST)

rubyonrails-talk
1

Hi Everyone,

Working on a REST-based web application, and I need some ammo in dealing with my supervisors and contractors.

Is it better to:

Method 1:   Take in one large XML-based POST request, which contains 1st, 2nd and 3rd level elements, and build the associated child and grandchild objects in the parent controller,

Method 2:   Instead use a number of smaller XML-based POST requests targeted at the appropriate child resources?

In this example, we have Routes, Stops and Visitors.

Using Method 1, the POST request would be aimed at the Routes controller, and the routes controller would parse the XML and build the stops and the visitors records. Using Method 2, each prior node of the XML document would make up a separate request, so there would be POST request against the routes controller, then for each route a series of POST requests against the Stops controller, and finally for each stop, a series of POST requests against the visitors controller.

From a development standpoint, I'm inclined to go for Method 2, but I'm facing some resistance. Can anyone offer some decent arguments in support in favor of Method 2? Or, if I'm wrong and Method 1 is the way to go, offer decent arguments in favor of Method 1 so that I understand where I'm confused?

Thanks!

-Jared

2

If you are thinking of implementing UD for the second level models, then method 2 definitely makes sense (ie, since you're coding UD, then C would likely belong there as well). R might be reserved for the high level if it is the primary point of contact.

Hopefully of some help.

Jodi

3

Hi Jared. I find it easier to build and test such an API using method 2.

Once you have things working and well-tested, you can create aggregate resources in the next iteration of your project.

If you’re wrapping the API with a client library like Active Resource, the difference in REST style will be transparent to the user anyway.

jeremy

4

i like method 2, i would design things from that perspective, once all is tested and functional build method 1 as a convenience method that parses the entire xml doc and delegates each task to the appropriate part of method 2 you have already built.

if the supervisors/contractors are non-technical, they are probably thinking that one request doing the entire task is easier for whomever is going to consume this service. Explain to them the benefits from the end users perspective of a design around method 2.