Should I return LaTeX format for math formulas in a REST API?

# API Design Postmortem: Handling Math Formulas in REST Responses

## Summary
- A quiz application API returned mathematical formulas exclusively in LaTeX format within JSON payloads
- This design forced clients to implement LaTeX rendering regardless of their capabilities
- Scalability concerns emerged due to varied client requirements and rendering complexity

## Root Cause
- The API required clients to process LaTeX for mathematical expressions without alternatives
- Key factors:
  - LaTeX expertise assumed universally available on client platforms
  - No fallback mechanisms for simpler renderings
  - Lack of client capability discovery features
- Treating all clients as LaTeX-capable VIOLATED Postel's Law (be conservative in what you send)

## Why This Happens in Real Systems
- Ecosystem pressures:
  - Academic/scientific domains use LaTeX as their lingua franca
  - Engineers copy domain-specific solutions without context awareness
- Common traps:
  - Prioritizing precision over accessibility
  - Oversimplifying client diversity ("Everyone uses MathJax!")
  - Assuming rendering consistency across platforms
- Time constraints favoring immediate solutions ("Just use LaTeX—it works")

## Real-World Impact
- Reduced adoption in constrained environments:
  - Mobile apps without LaTeX libraries
  - Screen readers failing with raw LaTeX
- Increased client-side complexity:
  - Forced bundling of heavy math libraries (+200-500KB)
  - Rendering latency on low-end devices
- Maintenance burden:
  - Formula versioning complexity when formulas change
  - Client-server LaTeX interpreter mismatch risks

## Example Code
```json
// Problematic approach: Single LaTeX representation
{
  "type": "formula",
  "format": "latex",
  "value": "\\int_{a}^{b} x^2 dx"
}

// Improved approach: Multi-format support
{
  "type": "formula",
  "representations": {
    "latex": "\\int_{a}^{b} x^2 dx",
    "mathml": "<math>...</math>",
    "unicode": "∫_a^b x² dx",
    "ascii": "integral(a,b) x^2 dx"
  }
}

How Senior Engineers Fix It

1. Offer multiple representations

   • Provide LaTeX alongside simpler formats (MathML/Unicode/plain text)
   • Use Content-Type negotiation
   • Include Accept headers: application/mathml+xml, text/mathml

2. Decouple rendering responsibility

   • Apply the Robustness Principle: “Be flexible in what you accept, conservative in what you send”
   • Handle formula rendering at client configuration time, not server-design time

3. Implement consumption hints

   "formula": {
     "default": "∫_a^b x² dx",
     "advanced": {
       "format": "latex",
       "value": "\\int_{a}^{b} x^2 dx"
     },
     "hash": "sha256-..."
   }

4. Circuit-breaker for complex formats

   • Offer downgrade paths in SDKs:

     getFormula({ fallback: 'unicode' })

Why Juniors Miss It

• Domain expertise bias:
  • Prioritize “correctness” over usability
  • Underestimate rendering variation across devices
• Experience gaps:
  • Lack exposure to non-browser clients (CLI, IoT)
  • Unaware of accessible math standards
• Tooling disconnect:
  • Assume JavaScript-heavy clients represent all use cases
  • Over-rely on external libraries without vetting dependencies