The original release of the SRP HTTP Framework managed all configuration details within inserts and specific stored procedures. The unfortunate side-affect of doing this, especially the when the configuration details within the insert were updated, was the need to recompile all stored procedures that were dependent on those inserts. As the library of web service routines grew, so did the task of recompiling all of these routines.

v1.0.1 introduced some changes by moving some of the configuration details into the SRP_HTTP_FRAMEWORK_SETUP record, which is stored in the SYSENV table. v2.0.0 completed this trend by having all of the remaining configurable details moved into SRP_HTTP_FRAMEWORK_SETUP. New application services (found in the HTTP_Services module) were created to access these settings, thus abstracting the method by which these details are maintained. For customers who are considering upgrading from v1.x to v2.0.0, this will require some minimal changes. Please refer to the Post-Installation Configuration article for information on configuring the SRP_HTTP_FRAMEWORK_SETUP record.

The other big change has to do with the way the RunHTTPService application service is called. The original version of this service had three arguments: NextServiceHandler, NextService, and NextURL. Over time it became apparent that these could be reduced to just two arguments, which are now named HTTPService and RemainingURL. This allowed us to refactor the HTTP_Service_Setup insert, reducing its line count by half, and making it much simpler to follow.

This invariably affected the argument signature and internal variables used by the actual web service routines. Previously, these routines used a generic service signature, even though only the first two arguments were ever populated. Now they only accept one argument, which is named RemainingURL to correspond with the same argument being passed to the RunHTTPService application service. The new sample HTTP service routines (HTTP_Entry_Point_Services, HTTP_Users_Services, and HTTP_Contact_Services) have updated comment blocks that clearly document all of the variables populated by the HTTP_Service_Setup insert. This will help the developer understand what information is available so that API logic can be written much easier.

  • No labels