Well, there is no URL that will pull that information directly. That is to say, this new service is not a web service. It is an internal service. You would need to create your own web service (e.g., HTTP_GETVERSION_SERVICES) and it would, in turn, make a call like this:
Thus, the BASIC+ web service should be HTTP_VERSION_SERVICES. My bad for making the previous suggestion...force of habit.
Why the change? Well, this is part of the campaign to rescue web applications from the RPC (remote procedure call) approach that has become the norm when SOAP (and other wrap-a-function-call-in-a-payload methods) was introduced. HTTP was designed primarily to identify URLs as paths to resources, not functions. This is why HTTP has verbs (aka methods) that provide us ways for acting upon these resources. Thus, the GET method in conjunction with the /api/version resource becomes a GetVersion service. Other methods (POST, PUT, DELETE, etc.) may or may not be added if further functionality is required, but the URL would remain the same as opposed to being forced to create new URLs such as /api/deleteversion, /api/postversion, /api/getversion, etc.
Yes, I am restating the Operation Philosophy of the SRP HTTP Framework, but I thought this discussion would be useful to apply the principles.
Comments
Well, there is no URL that will pull that information directly. That is to say, this new service is not a web service. It is an internal service. You would need to create your own web service (e.g., HTTP_GETVERSION_SERVICES) and it would, in turn, make a call like this:
VersionInfo = HTTP_Services('GetVersion')... and then add a
Case Service _EQC 'getversion'in http_entry_point_services?
The mud is slowly dissipating.
Yes, assuming you want a web service that follows this URL:
http://www.mywebsite.com/api/getversion
However, to start us on the correct path toward better HTTP etiquette, I might suggest the URL look like this:
http://www.mywebsite.com/api/version
Thus, the BASIC+ web service should be HTTP_VERSION_SERVICES. My bad for making the previous suggestion...force of habit.
Why the change? Well, this is part of the campaign to rescue web applications from the RPC (remote procedure call) approach that has become the norm when SOAP (and other wrap-a-function-call-in-a-payload methods) was introduced. HTTP was designed primarily to identify URLs as paths to resources, not functions. This is why HTTP has verbs (aka methods) that provide us ways for acting upon these resources. Thus, the GET method in conjunction with the /api/version resource becomes a GetVersion service. Other methods (POST, PUT, DELETE, etc.) may or may not be added if further functionality is required, but the URL would remain the same as opposed to being forced to create new URLs such as /api/deleteversion, /api/postversion, /api/getversion, etc.
Yes, I am restating the Operation Philosophy of the SRP HTTP Framework, but I thought this discussion would be useful to apply the principles.
If I see it often enough, it will eventually sink in