To simplify the creation of custom endpoints in the software factory, I have the following idea:

Imagine how convenient it would be to model endpoints easily.

For example, suppose you want to provide an interface to your CRM application for third-party tools. To achieve this, you need a way to view and manage certain entities like relationships and customers within the system.

Let’s consider a /customer endpoint where we can perform a few operations:

• GET → Retrieve a list of customers, with an option to pass a customer_id as a query string.
• PUT → Add a new customer.
• DELETE → Remove a customer.
• UPDATE → Modify a customer's details.

The GET operation would return a text in the body of the response with a 200 HTTP status code. For this, I propose creating a procedure that takes customer_id as a parameter.

(Side note: I am aware that query strings are not type-casted. Therefore, if a customer_id is provided, the service layer should validate whether it can be cast to the appropriate data type, in this case, an integer.)

GET Example
Here is a pseudo-code example for the endpoint:

create procedure dbo.api_get_customer(
	@qs_customer_id int -- QS stands for QueryString, explanation follows in the PUT section.

   ,@request_body nvarchar(max)
   ,@request_header nvarchar(max)
   ,@response_code int output
   ,@response_body nvarchar(max) output
   ,@response_header nvarchar(max) output
)
as
begin
   set @response_code = 200
   set @response_body = 'Lorem Ipsum is simply dummy text of the printing'
end

You can output the body in JSON, XML, or any preferred format.

PUT Example
For PUT operations, it would be helpful to specify that the endpoint expects a multipart form, which can be interpreted as variables in the subroutine.

To achieve this, you would define the parameters/fields expected in the form along with their data types. For example, we could expect a name as a varchar and logo_photo as a varbinary.

create procedure dbo.api_put_customer(
	@mf_name varchar(255) -- Specified through the domain system in the software factory
   ,@mf_logo varbinary(max)

   ,@request_body nvarchar(max)
   ,@request_header nvarchar(max)
   ,@response_code int output
   ,@response_body nvarchar(max) output
   ,@response_header nvarchar(max) output
)
as
begin
   set @response_code = 200
   set @response_body = 'Lorem Ipsum is simply dummy text of the printing'
end

PAT Tokens
To integrate this concept, we can enable the created interfaces in the PAT (Personal Access Token) list. We could add a checkbox to specify which methods should be available through the PAT system.

Swagger UI
To facilitate developers interfacing with the newly created endpoints, we could provide two versions of the OpenAPI/metadata specification: one with the endpoints and another with universal endpoints. This would allow for straightforward integration with Swagger UI.

What does this solve?
Well currently you can make open api’s via processflows. But you need to model a processflow, then create a process procedure that handles the calls. And You need to think of everything to for example receive data as multipart forms, querystring data you need to split out of the routings e.t.c. It normally takes allot of code to make a simple webservice/api endpoint.