The chat responses are generated using Generative AI technology for intuitive search and may not be entirely accurate. They are not intended as professional advice. For full details, including our use rights, privacy practices and potential export control restrictions, please refer to our Generative AI Service Terms of Use and Generative AI Service Privacy Information. As this is a test version, please let us know if something irritating comes up. Like you get recommended a chocolate fudge ice cream instead of an energy managing application. If that occurs, please use the feedback button in our contact form!

Provide Feedback

Feedback sent

Thank you for your feedback!

Provide Feedback

Please log in to provide feedback
Skip to content
Siemens Xcelerator Marketplace

Common API Guidelines

Version: 2.1.0

Last Changed: February 21, 2024 (see changelog)

Scope

These are Common API design guidelines RECOMMENDED for all Siemens developers working on internal and external APIs, as well as for our customers, partners, and anyone consuming or working with our APIs.

These guidelines MUST be applied to Siemens Xcelerator X products and solutions. Project teams MAY enhance these guidelines with additional restrictions based on their business needs, but we generally recommend that the guidelines listed here are still adhered to.

The goal of these guidelines is to help developers design simple, consistent, and easy-to-use APIs that can be easily consumed by API clients. API designers and integrators can focus on quickly providing value while avoiding the headache of trying to solve common API design or system integration problems.

Conventions used in these guidelines

This section specifies key words and phrases that are used for describing the severity of rule definitions. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC2119 and RFC8174 when, and only when, they appear in all capitals, as shown here.

Key Word                        Alternative Terms                                Definition
MUST"REQUIRED", "SHALL"This word means that the definition is an absolute requirement of the specification.
MUST NOT"SHALL NOT"This phrase means that the definition is an absolute prohibition of the specification.
SHOULD"RECOMMENDED"This word means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
SHOULD NOT"NOT RECOMMENDED"This phrase means that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
MAY"OPTIONAL"This word means that an item is truly optional. One may choose to include the item because it is required or because it enhances the product while another may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein this also applies vice versa.
Contact us