Survived a complete rewrite for a client just now.<p>The previous team blindly relied on a single method from Spring framework&#x27;s RestTemplate
for every rest service calls with SAP backend.<p><pre><code>    ResponseEntity&lt;T&gt; exchange(String url,
        HttpMethod method,
        HttpEntity&lt;?&gt; requestEntity,
        Class&lt;T&gt; responseType,
        Object... uriVariables)
        throws RestClientException</code></pre>
(ref: <a href="https:&#x2F;&#x2F;docs.spring.io&#x2F;spring&#x2F;docs&#x2F;current&#x2F;javadoc-api&#x2F;org&#x2F;springframework&#x2F;web&#x2F;client&#x2F;RestTemplate.html" rel="nofollow">https:&#x2F;&#x2F;docs.spring.io&#x2F;spring&#x2F;docs&#x2F;current&#x2F;javadoc-api&#x2F;org&#x2F;s...</a>)<p>This forsed them to create object models structured to match the complicated 
and inconsitent request and response JSON strings that SAP used, instead of creating the objects 
modeled after the business domains. The result was no surprise was a disaster and the client wasted five months with them and I had to redo and complete the project still on time.<p>I still see many teams make their function signatures in Java so convoluted like below and don&#x27;t know
what hit them.<p><pre><code>    interface ToDoService {
        ListToDoResponse listToDo(ListToDoRequest request) throws ListToDoException;
        AddToDoResponse addToDo(AddToDoRequest request) throws AddToDoException;
        .. and so on ..
    }</code></pre>