Ideas on 'overloading' HTTP_RESOURCE_SERVICES

r.od.akker

Suppose I want to convert data between the database and the API. For example I want to alter data before exposing it to the public. This means I also have to convert this back, when saving it to the database. In my case; I'd just like to 'protect' certain fields in the record and don't update them at all.

Since BASIC+ isn't OO I was thinking maybe I could implement something that works with callbacks. I'd like to have points in the HTTP_RESOURCE_SERVICE where I can 'break' in the code, make some modifications, and then proceed. So for example before parsing the json data to the ItemRec, I could clear this data and make sure it is skipped.

Any idea's on this? Have people already implemented it? I could create a copy of HTTP_RESOURCE_SERVICES and implement the custom logic for this endpoint there. But if anything changes in resource services, I'd have to do this in every piece of code that was copied from this. I'd rather not have copies of code, I'd rather re-use it.

I'm very curious about other user's point of views.

DonBakke

Personally I think the following would be a simpler (and more BASIC+ friendly) way of doing this:

• In the specific end point API code that calls HTTP_Resource_Services, get the Body using the GetHTTPPostString service, modify the content as required, and save this value back using HTTPPostString as the name in the Memory_Services SetValue service. (We never implemented a SetHTTPPostString service because we always assumed this would be handled directly in the SetOECGIRequest service...but this could also be changed).
  
• In HTTP_Resource_Services, instead of a callback, just read a configuration record that is directly associated to the current table. An easy way of doing this is to store a record in the dictionary for the current table. If it does not exist you can ignore it. If it does exist, it will contain additional data that you would have other retrieved from your callback and HTTP_Resource_Services would respond accordingly.
  

AusMarkB

In the specific end point API code that calls HTTP_Resource_Services, get the Body using the GetHTTPPostString service, modify the content as required, and save this value back using HTTPPostString as the name in the Memory_Services SetValue service.

This is how I've implemented it. That way http_resource_services still remains unaware and just does its thing.
I format the urls like this
api/myresource/resourceid/something

in the endpoint service http_myresource_services, the beginning of the PostItem has a case statement comparing 'something' to determine what it needs to do to the data. Each case has a gosub that manipulates the HTTPPostString as Don suggests and then returns allowing the PostItem code to continue as it would currently be.

r.od.akker

So if I'm correct, then you would first get the body, decode the JSON, delete or modify the items, encode the JSON again, put it back in the body, and then let the normal flow proceed? I have thought about this, but indeed I was missing the setter for http post string.

Meanwhile I have tried implementing the callback idea. I'm not sure if I will keep on this path, but for this particular problem it seems to work. In HTTP_RESOURCE_SERVICES, the PostDatabaseItem can be fed with a fourth parameter that contains the name of the callback. Then inside the decoding loop, the JSONType is being checked.

I added the callback here:
If CallBack NE '' then call @CallBack('GetJSONType', JSONType, ColumnName) end
This now allowed me to return the type 'SKIP' to JSONType, which I added to the case statement to make sure it does nothing. Then I created a subroutine which implements this service.

I figured I might later on use the same kind of procedure for data conversion.

I guess the downside is that I am editting HTTP_RESOURCE_SERVICES, so updates to the http framework are harder to implement.

DonBakke

You have summarized my suggestion and Mark's solution correctly. In light of this thread, I think I will add some proper setters to the HTTP_Services module.

In the end, however, I believe that any solution that works for you is a good solution. Time will tell whether you favor it or if you find deficiencies that annoy you in the long run.