GeneXus has the ability to automatically create REST Web Services using API objects (and also, for compatibility reasons, it is possible to configure Transactions that are Business Component (BCs) as Rest Web Services, configure Data Providers as Rest Web Services and configure Procedures as Rest Web Services).
By setting the necessary configuration, the data that encapsulates the API, Business Component, Data Provider or Procedure may be accessed through the web as a REST service using the HTTP protocol.
A Rest application requires a different approach than a remote procedure-based application.
In Rest, the focus is placed on a wide range of resources; for instance, a Rest application could define resources such as products, clients, purchase orders, etc.
So, the process to design an application like this would be to identify each one of its resources: remember that each resource has its own URI.
- A URI for the products and a URI for each product
- A URI for the Purchase Orders and a URI for each one.
Consider the methods that you need to implement. For example, to let end users access the list of products - GET, to access each product (GET), to insert a purchase order (POST) or to update an order (PUT). Check this article: REST Protocol considerations for more considerations to take into account when designing your API.
Besides, take into account the parameter types, it is recommended to use basic data types (scalar types such as numeric, string, date, GUID) when using the GET and DELETE verbs, because they will use the URL queryString to transfer it; the Output does not have this restriction.
In GeneXus, developing and/or consuming a Rest service is an easy task.
As you'll see in the following documents, a Rest service is generated by setting just an object property, and the specification document of this service is generated automatically.
With respect to consuming a Rest service (it can be generated by GeneXus or not), GeneXus provides the OpenAPI import tool.