2

Communication from Apex with huge REST Apis feels cumbersome to me as there is so much repetitive work involved with building Apex Objects that function as callout request params or responses.

This is especially bad when the API is not stable and you constantly have to re-adjust the DTOs.

I know there are ways to describe REST APIs. Swagger for example. I have also seen code gens for Swagger, but I would really like to hear more from Salesforce developers who have durable experience in working with huge APIs.

So just to restate what I want:

  1. Prevent the extensive manual creation of dumb DTO objects
  2. Allow to easily adapt to API changes.
  3. Minimize Code that juggles with HTTP or JSON details.

I'm especially interested in how that is solved in other languages: Java or .NET in comparison to Apex. What's the state of art in consuming REST?

5
  • 3
    I don't feel this is the correct place for this question. It is very likely to encourage discussion and lead to opinion based answers. Your request related to non-Salesforce languages is off topic as well.
    – gNerb
    May 16, 2019 at 20:05
  • 1
    What would be a better place for a question on Pattern for Apex Rest consumption?! What is bad with discussion and opinions. This is what I am interested in and I also would like to get answers from people who can put in insights from other areas. I can just hope that your opinion doesn't count to much in this forum. May 16, 2019 at 21:14
  • 2
    Discussions and opinions to not lend themselves well to the Q&A format of the site. A better place would be Salesforce Developer Forums. As per the help center subjective questions are a dicey area. While there are some good subjective questions and your question does have some value; I feel that it is better to try to avoid them. As evidenced by the votes, some agree and some disagree.
    – gNerb
    May 16, 2019 at 21:44
  • 1
    On This is especially bad when the API is not stable. If an API changes frequently which breaks things at consumer end, then definitely there is a lack of good change management. An API should allow consumers to adapt once published and allow them to consistently call it while being able to publish new versions. If new versions requires the consumers to frequently update their code, then it doesn't really fit in parameters of good design. New version should be more targeted to add feature without really breaking existing things and leaving for consumers as what they want to consume vs. not
    – Jayant Das
    May 17, 2019 at 1:51
  • I always version the API, v2, v3 etc, May 17, 2019 at 8:12

1 Answer 1

2

A lesson I've learned for incoming requests where structure varies over time is to do your own deserialization/serialization to avoid getting locked into no longer valid signatures (in managed packages).

So something like this:

@RestResource(urlMapping='/xyz/*')
global with sharing class MyRest {

    @HttpPost  
    global static void post() {

        RestResponse req = RestContext.request;
        RestResponse res = RestContext.response;
        try 
            res.responseBody = Blob.valueOf(dispatchPost(req.requestURI, req.requestBody.toString()));
            res.statusCode = 200;
        } catch (EndUserMessageException e) {
            res.responseBody = Blob.valueOf(e.getMessage());
            res.statusCode = 400;
        } catch (Exception e) {
            res.responseBody = Blob.valueOf(Strings.sanitizedMessage(e));
            res.statusCode = 500;
        }
    }

    private String dispatchPost(String uri, String requestJson) {
        // Parse URL to decide which method/class should handle and delegate to that
    }

    ...
}

If you want to do lots of manipulation of the incoming or outgoing data in Apex then the DTOs generated by https://json2apex.herokuapp.com/ are obviously helpful. I don't know of more flexible tools, so will be interested to see if others do.

Not the answer you're looking for? Browse other questions tagged .