Migration for External API

We improved the External API editor logic.

Bug fixes:

  • Correct processing of names of models, fields and the entire External API entity with synchronization of elements in the database
  • Correct block name API [Request-Type] Request: [name]
  • Sorted VarIn fields in descending order of importance
  • Sorted VarOut fields in descending order of importance
  • If only 1 response is specified - in the BP used the Body field
  • If more than 1 response is specified - in the BP used a set of Body_[code] fields, starting from the smallest (200,300,400,500)
  • Removed status_conn_ for multiple response types. Replaced with only one status_conn
  • Removed SSE response/request type
  • Added JSON[] response/request type - JSON Array. In cases where the top level of the response/request contains a JSON array (objects, strings, numbers, etc.)
  • The HTTP version, HTTP method variable types in the BP have been replaced with enums
  • The request_type and sse variables have been removed from the BP
  • Correct handling of headers, queries, query variables when using default values ​​and overwriting values ​​from a block
  • Fixed timeout handling
  • Add default headers is activated by default when creating an External API
  • Follow redirects and max redirects count are set by default, similar to Postman
  • Correct handling of the logic of various types of requests/responses
  • For XML, the name of the root model from the response is used at the top level of the model

Steps to fix possible issues after migration to the improved External API

Figure 1 shows an example of an External API that will be used for migration.

Figure 2 shows an example of the BP of this External API.

Figure 3 shows an example of the BP of this External API after migration.

Figure 4 shows the necessary changes after migrating External API.

  • The data types for the variables HTTP version, HTTP method have been changed and are now marked as invalid. They need to be replaced with a valid type
  • The variables error_, success_ have been removed in VarsOut. If they were connected, they need to be connected to error, success
  • You need to manually delete the old response_status_ from the End Block if it was connected to the End block

For projects that did not use External API in the BP as blocks, you should delete old requests and create them again (or write the project number in the thread). Migrations were carried out only for projects that used External API as blocks.