Imagine our car getting repaired without even taking it to an automobile service centre. A few years back, Tesla, the car manufacturing company, famously did that when it issued an over-the-air repair to their cars. Tesla's software got updated to detect charging problems and help decrease the charging rates (cascading effect) to avoid overheating and hence avoid engine fires.

Design for intent is a term that's used in structural and automobile fields for parameterized changes, and we will learn how it benefits REST API services as well.

Design for intent is a method that expresses the different relationships between objects so that changes to one object automatically propagates changes to others. In Tesla's case, the decreased number of charging cycles (cascading effect) helped to avoid overheating of the engine.

In a RESTful API world, the API should be developed to ensure they meet the requirements of the use cases, provided and faced by the users, but without exposing the internal business objects. Design for intent is a strategic design pattern that's intended to influence or result in specific and additional user behaviors.

To relate the design for intent implementation within our investor service example, we should provide the mechanism to update the investor's portfolio automatically whenever the new (type) stocks get added to the investor object:

As you can see in the preceding diagram, the intention of the API is to add a new stock; however, it should have a cascading effect on the investor's portfolio as well—maybe a new stock type should get added, the total number of stocks needs to be updated, and so on. This is abstract to the app developer. The same applies when stocks are deleted as well.

Please recollect the granularity of APIs discussion from Chapter 2, Design Strategy, Guidelines, and Best Practices, as choosing the right granularity of APIs plays a vital role in the design for intent strategy. In this chapter's example, we have provided a simple update method for adding the stock types to the investor's portfolio, and readers are encouraged to develop more functionalities as part of this pattern ensures having the right granularity (coarse-grained versus fine-grained) of APIs for the update and delete stock types within an investor's portfolio. Consider the following code:

........ 
public Stock addNewStockToTheInvestorPortfolio(....) { 
  if (......)) { 
      designForIntentCascadePortfolioAdd(investorId); 
      return ......; 
  } 
...... 
} 
......... 
......... 
public boolean deleteStockFromTheInvestorPortfolio(....) { 
  ...... 
  if (....) { 
     .... 
     designForIntentCascadePortfolioDelete(investorId, deletedStatus); 
    return .......; 
      } 
......... 
 
private void designForIntentCascadePortfolioAdd(...) { 
            ..... 
      } 
private void designForIntentCascadePortfolioDelete(...) { 
            ........; 
      } 
} 

The output of the preceding code is as follows:

The preceding screenshot and code is the sample implementation (code snippets) that we can see in InvestorService.java. This also shows a console message when the Delete and Add APIs are called with the Postman tool.