sap-api-style

# SAP API Style Guide

## Related Skills

- **sap-cap-capire**: Use for OData service documentation, CAP API patterns, and service definition standards
- **sap-fiori-tools**: Use for API consumption patterns, Fiori app integration, and OData best practices
- **sap-abap**: Use when documenting ABAP APIs, implementing REST services, or following API design patterns
- **sapui5**: Use for frontend API integration, OData consumption, and UI service patterns
- **sap-btp-cloud-platform**: Use for BTP service API documentation and integration patterns

## Table of Contents

1. [Overview](#overview)
2. [When to Use This Skill](#when-to-use-this-skill)
3. [Quick Decision Tree](#quick-decision-tree)
4. [Core Principles](#core-principles)
5. [Quick Reference Tables](#quick-reference-tables)
6. [Templates Available](#templates-available)
7. [Reference Files](#reference-files)
8. [Instructions for Use](#instructions-for-use)
9. [Common Pitfalls to Avoid](#common-pitfalls-to-avoid)
10. [External Resources](#external-resources)
11. [Updates and Maintenance](#updates-and-maintenance)

## Overview

This skill provides comprehensive guidance for documenting SAP APIs according to official SAP API Style Guide standards. It covers all major API types and documentation approaches used across the SAP ecosystem.

**Documentation Source**: [https://github.com/SAP-docs/api-style-guide](https://github.com/SAP-docs/api-style-guide) (76 files extracted)

**Last Verified**: 2025-11-21

## When to Use This Skill

Use this skill when:

- **Creating API documentation** for REST, OData, Java, JavaScript, .NET, or C/C++ APIs
- **Writing OpenAPI specifications** for SAP API Business Hub
- **Reviewing API names** for SAP naming convention compliance
- **Documenting API parameters, responses, operations** with proper formatting
- **Creating manual API documentation** using SAP templates
- **Writing documentation comments** in source code (Javadoc, JSDoc, XML comments)
- **Implementing API deprecation** following SAP lifecycle policies
- **Developing developer guides** or service documentation
- **Performing quality checks** on API documentation
- **Publishing APIs** to SAP API Business Hub

## Quick Decision Tree

### What Type of API?

```
REST/OData API
├─ Auto-generated (OpenAPI/Swagger)?
│  └─ references/rest-odata-openapi-guide.md
│     • OpenAPI specification standards
│     • Package, API, operation descriptions
│     • Parameters, responses, components
│     • SAP API Business Hub requirements
│
└─ Manually written?
   └─ references/manual-templates-guide.md
      • REST templates (2-level: overview → method)
      • OData templates (3-level: service → resource → operation)
      • Complete field requirements
      • templates/ directory for ready-to-use files

Native Library API
├─ Java → references/java-javascript-dotnet-guide.md
├─ JavaScript → references/java-javascript-dotnet-guide.md
├─ .NET (C#) → references/java-javascript-dotnet-guide.md
└─ C/C++ → references/java-javascript-dotnet-guide.md
    • Documentation comments structure
    • Language-specific tags
    • Templates for classes, methods, enums
    • Complete code examples
```

### What Task?

```
Naming
└─ references/naming-conventions.md
   • REST/OData naming (resources, parameters, URIs)
   • Native library naming (classes, methods, constants)
   • Common mistakes to avoid

Writing Descriptions
└─ references/rest-odata-openapi-guide.md
   • Package descriptions
   • API details (info object)
   • Operations, parameters, responses

Quality Assurance
└─ references/quality-processes.md
   • Complete API Quality Checklist
   • Review workflows
   • Development team guidelines

Deprecating APIs
└─ references/deprecation-policy.md
   • Lifecycle states (beta, active, deprecated, decommissioned)
   • Timeline requirements (12+ months support)
   • Required metadata (x-sap-stateInfo)

Developer Guides
└─ references/developer-guides.md
   • Structure guidelines
   • Content selection
   • Code sample standards
```

## Core Principles

### 1. Consistency Across SAP APIs

All SAP API documentation follows consistent conventions:
- **Naming**: Language-specific (camelCase, PascalCase, kebab-case)
- **Structure**: Hierarchical with clear navigation
- **Formatting**: Sentences start with capitals, end with periods
- **Language**: American English

### 2. API-Type-Specific Standards

| API Type | Standard | Tool | Documentation |
|----------|----------|------|---------------|
| REST | OpenAPI 3.0.3 | Swagger | [Spec](https://spec.openapis.org/) |
| OData | v4.01, v3.0, v2.0 | Various | [OData.org](https://www.odata.org/) |
| Java | Javadoc | javadoc | [Oracle](https://www.oracle.com/technical-resources/articles/java/javadoc-tool.html) |
| JavaScript | JSDoc 3 | jsdoc | [JSDoc.app](https://jsdoc.app/) |
| .NET | XML Comments | DocFX | [Microsoft](https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/xmldoc/) |
| C/C++ | Doxygen | doxygen | [Doxygen.nl](https://www.doxygen.nl/) |

### 3. Progressive Disclosure

Documentation organized hierarchically:
- **High-level overviews** provide context and navigation
- **Detailed references** cover specific APIs, methods, operations
- **Examples and templates** demonstrate practical usage

### 4. Quality Standards

All documentation must:
- ✅ Be reviewed by User Assistance (UA) developers
- ✅ Use consistent naming and terminology
- ✅ Include complete parameter and response descriptions
- ✅ Avoid sensitive data in examples
- ✅ Provide working code examples
- ✅ Maintain accurate links and cross-references

## Quick Reference Tables

### Character Limits

| Element | Limit | Use Case |
|---------|-------|----------|
| API Title | 80 | `info.title` in OpenAPI |
| API Short Text | 180 | `x-sap-shortText` |
| Package Short Desc | 250 | Package tile description |
| Operation Summary | 255 | Operation summary line |
| Description | 1024 | General descriptions |

### API Naming Rules

**General Rules** (all API types):
-