Approaches with pros and cons on Passing data to an Apex Rest api service from a legacy application

If you are a salesforce developer or an architect, one of the challenges is to question what is the best way to pass data from an external application to a REST service which you plan to build in Salesforce. This post would help you to walk through the options of each approach , pros and cons and help you make the right decision. The real question which most of the developers and architects tend to wrestle with is to decide between allowing  a JSON string to be passed from the legacy application, or create an object structure to be passed from the client to salesforce and how do we decode this in salesforce to process the results?

When you build a REST service in Apex, you have 2 options to build the service.

  1. Create a method allowing parameters like a String or an Object structure
  2. Creating a method with no parameters .

Let us explore both the approaches in details.

Method with parameters approach.

Here is a code snippet which would explain the approach.

Passing data with  Method parameters.

@HttpPost
//The method here accepts an object CoursesData as parameter.
global static String processFileWithParameter(List<CoursesData> courses)
{
       String response;
       for(CoursesData courseObj: courses )
       {
         response = 'courseid'+ courseObj.CourseName;
         response += 'courseName'+courseObj.CourseId;
       }
 return response;

}
//This is the class which would be used to pass data between legacy application and apex rest service.
global class CoursesData
{
     public String CourseId ;
     public String CourseName;
}


public class Courses
{
       public Courses(){
     Courses = new List<CoursesData>();
}
     public List<CoursesData> Courses;

}

 

2. Method with no Parameters approach

@HttpPut
//You can see this method processFile does not have any input parameters.
global static String processFile()
{
  String response;
 //The below code will deserialize any json input to an object easily. With no parameters, you have to read the data from the request object.
  Courses result = (Courses)JSON.deserialize(RestContext.request.requestBody.toString(), Courses.class);
  system.debug('result ' + result);
 for(CoursesData courseObj: result.courses )
 {
  response = 'courseid'+ courseObj.CourseName;
  response += 'courseName'+courseObj.CourseId;
 }

return response;
}

 

Comparing the 2 options

 Method with parameters Method with no parameters
Pros 1. Strongly typed as it would force the client to follow a data structure.

2. Easy to debug on both sfdc and client side and validate the data and reduces maintenance time.

3. provides you a contract definition between the calling client and sfdc.

4. Works well for high volume data inputs where you can limit the number of records passed using collection size.

1. Loosely typed and can be very flexible

2. Change in data parameters does not result in code changes on the calling client which is the java application.

Cons 1. Change in parameters or attributes of the object structure would result in code changes on the calling client. 1. can result in too much time debugging data transfer issues because the client can change the input and sfdc needs to handle it and result in too much maintenance time.
 When to use This approach can be used if you want to process a lot of records like 100,000 records from the legacy application in a batch processing mode. This works well when you have an one off apex rest service need where you have little data to be transferred to be passed from legacy to salesforce and you want to allow great flexibility between the calling application and rest service.

Based on the above approaches, you can decide which approach will work for you and talking to the calling application, you can decide the best approach. Here are some key takeaways for this blog.

  1. Never create any parsing code to parse the json which will add significant overhead to your JSON parsing.
  2. Always create object structures to deserialize the JSON input to an object structure and use it to do you DML.
  3. Never expose Salesforce custom objects as method parameters.

Please feel free to post your comments below and feel free to email me at buyan@eigenx.com for any further questions.

Please subscribe

Subscribe to our mailing list and get tips to maximize salesforce to your email inbox.

Thank you for subscribing.

Something went wrong.

Share:
buyan47

Author: buyan47

Hi there! My name is Buyan Thyagarajan. I am a Salesforce consultant specializing in Higher Education, Manufacturing and Marketing Automation. My blogs will help you to maximize your Salesforce CRM investments, prevent problems beforehand and make the right decisions. If you need to talk to me right away, you can email me at buyan47@gmail.com or call me at 302-438-4097

Leave a Reply

Your email address will not be published. Required fields are marked *