I have written my fair share of RESTful API but am no expert by any measure. I had never given enough thought about the HTTP Verbs I should be using (like, PUT, POST, PATCH) while writing API. If a resource had to be created, I would automatically go for POST (_never considered the idempoten_cy angle at all) and if a resource had to be modified, I would go for PATCH.
On one of my API assignments, I decided to make a very conscious and deliberated choice of the verbs I will be using; and an API in particular got me thinking.
I had to write an API to modify a resource and this resource happened to have nested resources and numerous attributes. I soon realized that it wasn’t so straight forward to create an elegant PATCH API due to the sheer number of attributes on this resource that can potentially get modified (Why did you design a resource with so many attributes in the first place? you might ask. But that is a topic for another day)
So, coming back to the task in hand, I was aware of only two choices to go about writing a PATCH call. Either, send just the attributes requiring modifications to the API (Approach 1) or end the entire resource to API after making changes to the necessary attributes at consumers’ end (Approach 2). We will examine both the approaches in the context of the below two classes (Employee and Address)
public class Employee
{
public int EmployeeId {get; set;}
public string EmployeeName {get; set;}
public Address EmployeeAddress {get; set;}
public string WorkLocation {get; set;}
public List<string> PreferredWorkLocations {get; set;}
}
public class EmployeeAddress
{
public string HouseNumber {get; set;}
public string AddressLine1 {get; set;}
public string AddressLine2 {get; set;}
}
**_Approach 1: _**The consumer of the PATCH API will send the entire resource, after changing a few select attribute that need to be modified. At the API end, the PATCH payload will be handed over to the repository layer which would then update the entire resource to the database. Other than some basic validations, no additional work is needed at the API end. A sample PATCH call (almost a PUT) would look like below
api/ModifyEmployee/{empId}
{
"EmployeeName" : "ename",
"EmployeeAddress" : {
"HouseNumber" : "F32",
"AddressLine1" : "Addr1",
"AddressLine2" : "Addr2"
},
"WorkLocation" : "Brazil",
"PreferredWorkLocations" : ["Brazil","France"]
}
#loadtesting #quality assessment (qa) #scala #testing #extractdata #jmeter #json #postprocessor
