The MSPro Boomi Collection
About
Good Practices & Patterns
Good Practices & Patterns
  • Markus' Boomi Integration
  • Implementation Patterns
    • The Cache Challenge
      • The Get-Or-Create Use-Case
      • PropCache Scripts
    • State Management
      • Example Scenario
      • State-Management in general
      • State-Management Functionality
      • Technical Solutions
        • Boomi File-System Implementation
          • saveState
          • readState & fetchStates
    • Exception Handling
      • Exception vs Error
      • Basic Rules
        • Aggregating Exceptions
      • Exception Handling Pattern
        • User-Defined Exception Messages
        • Catch Exceptions
      • The pattern in practice
        • API Error Handling
          • Single Record Strategy
            • Single Record RES
          • Many Records Strategy (Array)
            • Many Records RES
        • Pre-Condition Check
    • SQL Patterns
      • Script Header
      • General Rules
        • Check using RowCount
        • Check if record exists
        • Pagination and Sorting
        • Parameter - Best Practices
        • Use JSON as a complex parameter
    • Process Patterns
      • Process Route Implementation Pattern
      • Sub-Process or Process Route
    • DateTime
      • The Boomi datetime dilemma
      • Database and Flow
      • Groovy
      • Data Hub
      • Get Current Date
    • Groovy Script Patterns
      • Dynamic Document Properties
      • Dynamic Process Properties
      • Documents
    • Array Elements to Documents
  • MSPro Services
    • Intermediate Storage
      • Example Processes
        • Docs 01 - Update and Create
          • sub.SampleData.Invoice
        • 02 - Upsert and Get
    • Render Templates
  • Tips
Powered by GitBook
On this page
  1. Implementation Patterns
  2. Exception Handling
  3. The pattern in practice

API Error Handling

Good practices for API error respones

Last updated 6 months ago

APIs must be designed for two scenarios: (see here)

  • The Green Path - stands for SUCCES and responds the expected data (success profile).

  • The Red Path - stand for failure and responds Information about the failure.

There are a couple of good practices for APIs and I wanted to mention a few of them here:

  • Do use one profile for a successful response (http-20x) j.GPR.KeyValue.GET.RES

  • Do use one profile for all non-success responses (not http-20x) j.API.Error.RES

Do use the same error profile in all end-points / services, and place it on a prominent place in your repository - it is shared!

There is only one j.API.Error.RES and this profile is the basis for your error pattern. However, you will see later that there is a second error profile called: j.API.Errors.RES (plural), which is used when we work with arrays.

  • Use http-200 when you return a response body. Even if it is an empty Json, like { }, it is a Json and it is a non empty body -> 200.

  • Use http-204 when you don't return any data - no body.

The API logic sub-process

The sub-process looks like this:

  1. It implements the API end-point logic wrapped into the top-catch block,

    1. where the exception is handled and

    2. turned into an j.API.Error.Res

If we look into func.GetKeyValue() we will not find a try/catch block. Instead, when the business rules shape fails, we turn the failure (error) into a controlled exception and abort execution. The parent (top-level) catch will handle this exception!

j.GPR.KeyValue.GET.RES and j.API.Error.RES
API Logic Pattern with exception handling