AJAX vs REST - Architecting a Lean Core

In the SAP Edition, developers have the choice of using AJAX or REST APIs when connecting to the backend. The most common way, is assigning a class directly to the application —which  implements the /NEPTUNE/IF_NAD_SERVER interface. 

Consuming REST APIs built using the API Designer are also simple to consume in the App Designer, so which is the best approach? 

Comparison of REST vs AJAX approach

Note - It's possible to combine AJAX and REST APIs in the same application. Read this community post which discusses this topic.

Which is more "Clean"?

The less custom code you have the better. Having a single back-end class responsible for one business entity improves maintainability and follows the DRY approach. By building REST APIs you can broaden the scope of your development efforts and leverage these software assets - broader than just your Neptune App developments.

Having a single class responsible, provides the following benefits:

• Maintainability: Easier to understand, test, and modify.
• Reusability: Code can be reused in different parts of the system.
• Stability: Reduces the risk of unintended side effects.
• Upgrade Stability: Makes upgrades less risky.

This "lean core" approach, where ABAP classes per business object are created and exposed via /NEPTUNE/IF_RESTAPI. By creating a library of common SAP master and transactional objects, you'll establish a foundation of centralized APIs that can be leveraged across Neptune Apps, Neptune Open Edition and your broader IT landscape.

Performance Considerations

Helder's blog shows that there are no significant performance penalties when using REST instead of AJAX calls. All design patterns, including offline syncing, are possible.

Real-World Example

Consider a mobile purchase order approval application. The "traditional" Neptune approach would be to develop a purpose-built DPC class that extracts purchase orders and implements approval (release code) functionality. However, if you create a REST API that can read and release purchase orders - you can reuse that API across other processes in your business.

In a recent SAP Business Process Automation (SBPA) project for Accounts Payable invoice processing, a Neptune-powered REST APIs enabled SBPA Action Projects to seamlessly access vendors, purchase orders and goods receipts data from SAP. In addition, we provided non-SAP users ability to view purchase order details via an Adaptive Framework (Open Edition) application.

Exposing SAP Content to Neptune Open Edition

The Neptune Open Edition has great functionality that can be used in combination with SAP objects—think workflows beyond SAP users, PDF printing, and external-facing portals. If you have exposed your SAP objects via REST, you can also reuse them here!

Here is an example of displaying purchase orders from SAP in the adaptive framework using our acceleration framework called Cruise.

Conclusion

By adopting REST APIs as your preferred approach for core transaction and master data access in Neptune SAP Edition, organizations can build a strategic library of reusable services that serve multiple enterprise needs while maintaining deployment simplicity. One class per business object can be built—we like to call this the "Lean Core".

While this modular service architecture requires slightly more upfront design consideration, the significant long-term benefits make it the clear choice for all new Neptune initiatives.

Interested to hear other opinions from the Neptune Community!