While helping develop the new Student Web Service Enrollment resource, released just last week, the development team came across a RESTful design decision related to making our services more chatty or chunky. So what is the difference?
Chatty services tend to be ones that return simplified information and use more fine-grained operations. Chunky services tend to return complex hierarchies of information and use coarse operations. In other words, the difference is that chatty services require more calls than chunky services to return the same information but allow more flexibility to return only the information that is actually required.
– Rory Primrose (http://www.neovolve.com/page/WCF-service-contract-design.aspx)
This is a discussion we often have while designing our RESTful web services here at the UW. There is no clear cut answer on which is better to use because your design decision depends on the use cases of the consuming applications. For the Enrollment resource, we knew most applications would want all the student’s transcript data in one GET request, which led us to design a chunky interface.
Since we were retrieving an entire student’s academic history in one call our performance numbers for this resource was much slower than our other resources. Given our immediate clients wanted this exact design and our clients understood that retrieving years worth of data is not a fast operation; we decided that the performance numbers for our chunky design was okay. However we did not want to handcuff our future users and have them suffer the performance penalty if they only wanted a subset of the data like a student’s Majors data. With this in mind, we decided to offer a non-chunky (chatty) interface that provided the Majors and ClassLevel data and included a href link to the other half of a student’s transcript data. This was a significant performance improvement for the resource and incurred very little development time to offer this additional chatty pay load.
The educational cost of offering additional options to the client developers meant we had to help guide choices of when its better to use a chatty or chunky interface. I put together some performance related data in hopes that it would help client developers decide on when to use a chatty interface vs a chunky interface. The data below is a combination or real and calculated data. Due to the lack of time I was not able to develop an appropriate test harness to provide real numbers for all test cases.
The numbers below are based on a student with 9 enrollments totaling 35 registrations. There are 4 SWS resources here in play – Enrollment Search, Enrollment, Registration Search and Registration. Here is the call path to get to all the data when making multiple chatty calls back to the web service. EnrollmentSearch -> Enrollment (includes Registration Search) -> Registration.
To help with chart translation:
Chatty = Verbose Off
Chunky = Verbose On
|Enrollment Search Chunky||4.52||Based on real load data from our test environment|
|Enrollment Search Chatty Sequential GETS||12.1||(9 * Enrollment Chatty) + (35 * Registration Resource) + Enrollment Search Chatty|
|Enrollment Search Chatty Multi-Threaded GETS||2.5||(2 * Enrollment Chatty) + (6 * Registration Resource) + Enrollment Search Chatty|
|Resource Type||Response Time (Seconds) – One Request|
|Enrollment Search Chatty||0.25|
|Enrollment Chatty (Includes a Registration Search call)||0.50|
The mainframe only serves 6 concurrent requests at a time (possibly only 4 in our test environments).
The purpose of this analysis is to help a client developer strategize their calls to a RESTful web service. It also allows service developers to plan on future RESTFul designs when thinking about payload verbosity as it relates to performance.
I hope this helps. It has helped me learn more about RESTFul web services by going thru this exercise.