next »

[Huy H.]

We are designing a REST web service server application.  So far so good following the WS* field attributes.  We've been using a combination of WSPath, WSParam, and WSHeader go the the parameters we need.

What we find at the moment is that our web service "handler" function parameters is getting quite verbose and repetitive, some would even say messy.

PUBLIC FUNCTION file_attach_post (
  request      T_FILE_ATTACH_REQUEST,
  client_id    STRING ATTRIBUTE(WSHeader, WSOptional, WSName = "X-VTM-client-id"),
  client_token STRING ATTRIBUTE(WSHeader, WSOptional, WSName = "X-VTM-client-token"),
  machine_id STRING ATTRIBUTE(WSHeader, WSOptional, WSName = "X-VTM-machine-id"),
  user_id STRING ATTRIBUTE(WSHeader, WSOptional, WSName = "X-VTM-user-id")
)

For us, most of the WSHeader fields are for auditing purposes, they are not actual parameters for the web service call.  And for every web service we define, we need to add the same header information.  This is unnecessary repetitive, and at the same time, when the "client" code is generated from the openapi.json, these fields become parameters on the other side as well.  Overall, not the cleanest way.

We look further at this and we see that the documentation describes another way of getting the HTTPHeader information using WSContext:
                               
https://4js.com/online_documentation/fjs-fgl-manual-html/#fgl-topics/c_gws_restful_high_level_handling_http_headers.html

I would like to remove those WSHeader variables from our function and access them through a different way.  However, we find that the context DICTIONARY only provide access to a limited  set of keys (Media, BaseURL, Scope, and Content-Type) -- far from what we were looking for.  We do not see our X-VTM-* variables, what are we missing here?

We also tried using com.WebServiceEngine.GetHTTPServiceRequest() function to get the HTTPServiceRequest, but that seems to be only used for low-level REST service.

So question: Is there a way I can access arbitrary HTTP headers in a high-level REST framework design that I'm not aware of?

[Sisavanh S.]

Hi,

Indeed there is an issue, you should be able to use WSContext to retrieve the headers.
I've filed bug:
GWS-973: WSContext does not retrieve all the headers

Thanks for reporting.
Best regards,
Sisa.

[John T.]

Hi,

If you are using a delegate program with your web service, which I assume you are, you can get access to the service request (com.HttpServiceRequest) and therefore all the headers.

Then you can also set headers with com.HttpServiceRequest.setResponseHeader() in the delegate program.  If you prefix the header you are setting with X-FourJs-Environment- then you can access the header via the context dictionary from your web service function.

So in the delegate program:
call req.setResponseHeader("X-FourJs-Environment-X-VTM-client-token", req.getRequestHeader("X-VTM-client-token" ))

and then in the service function:
let client_token = context["X-VTM-client-token"]

Per the response from Sisa it sounds like all the headers are meant to be in the context dictionary.  That would have been easier, but as we are using a delegate it is not too much trouble.

Just doing a bit of checking on this I notice that one of the headers I set also comes through to the dictionary without a key name.  Strange.  So I am seeing both:
    X-jjttest = this is jjttest       (as in the key and data)
and
     = this is jjttest     (so no name for the key)

Maybe all part of the same bug.


John

[Huy H.]

I saw the same "blank-key" in the context dictionary when I did my testing.  I suspect it's related to the bug Sisavanh is referring to.

John, I'm not sure what you mean when you mention a "delegate program" for a web service, can you elaborate more. 

Thus far, when we implement REST using the "low-level" framework in Genero 3.20, the call to obtain the com.HttpServiceRequest via com.WebServiceEngine.getHTTPServiceRequest(-1) is available for us.  But it looks like when we're using the high-level framework design, calling com.WebServiceEngine.getHTTPServiceRequest(-1) within our module that has been registered to handle the REST request is a little too late.  When we do that, it just waits indefinitely until the next web service hits.

[John T.]

Hi Huy,

We used delegation for security and checking other bits and pieces.  This basically just involves adding the DELEGATE tag to the EXECUTION element of your .xcf file.
The delegate program is then called first.  In the delegate you can access the HttpServiceRequest as you can with the lower level framework.  Then you can set headers which you get access to via the context dictionary in your high level service (as in my sample below).   We are also using WSScope so we set the users scope in the delegate as these are stored in our database, i.e call req.setResponseHeader("X-FourJs-Environment-Scopes", scope).

Here is the link to a .xcf file with a DELEGATE tag:
https://4js.com/online_documentation/fjs-gas-manual-html/#gas-topics/c_gas_delegate_configuration.html

And here is a link to Fourjs sample delegate program:
https://4js.com/online_documentation/fjs-gas-manual-html/#gas-topics/c_gas_delegate_example.html

John

[Reuben B.]

To answer Huys question

John, I'm not sure what you mean when you mention a "delegate program" for a web service, can you elaborate more.

I would go up 1 level with the links from Johns answer to https://4js.com/online_documentation/fjs-gas-manual-html/#gas-topics/c_gas_how_to_implement_delegation.html and you can read through the various pages which include Johns 2 links.

Reuben

[Huy H.]

Very interesting!  Thanks for the info John and Reuben.