Trading Networks 10.3 | Administering and Monitoring B2B Transactions | Service Development Help | Working with REST API Descriptors
 
Working with REST API Descriptors
 
Overview of Creating a REST API Descriptor
Creating a REST API Descriptor from a REST Resources
Editing General Information for a REST API Descriptor
Changing the Available MIME Types for a REST API Descriptor
Working with REST Resources in a REST API Descriptor
Viewing REST V2 Resources in Group by Tags Mode
Running a REST V2 Resource Operation from REST API Descriptor Editor
About REST Definitions
Viewing the Swagger Document for a REST API Descriptor
Mapping Integration Server Data Types to Swagger Data Types
Creating a REST API Descriptor from a Swagger Document
Publishing REST API Descriptors to API Portal
A REST API descriptor provides a way of describing the operations provided by one or more REST resources together with information about how to access those operations, the MIME types the resources consume and produce, and the expected input and output for the operations. Fundamentally, a REST API descriptor is composed of REST resources and information about how to access those resources. Using this information, Integration Server creates and maintains a Swagger document for the REST API descriptor. Integration Server generates the Swagger document based on version 2.0 of the Swagger specification.
You can create a REST API descriptor from REST resources created using either the legacy approach (invoked using the rest directive) or the URL template-based approach (REST V2 resources invoked using the restv2 directive). You can also create a REST API descriptor containing REST V2 resources from a Swagger document.
For information about the approaches for configuring REST resources, see Approaches for Developing REST Resources.
Notes:
*Documentation for the REST API descriptor assumes back knowledge of REST concepts and the Swagger specification version 2.0.
*The information provided in this chapter applies to both the types of REST resources, that is, resources created using the legacy approach and those created using the URL template-based approach, unless explicitly specified for a particular type.