Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
warning - changing http_resource_services
I am posting this just in case someone decides to go down the path I did and all works fine...UNTIL!!
I had a few legacy dict fieldname that were not very 'descriptive' to an outside, so I created more a more descriptive field name for the web guy to use.
Of cause these were not Master fields.
These fields were not getting thru on the GET.
In resource_services it checks for the master flag and only passes those through. Ok don was being a bit neat and tidy I thought, so bugger that, I will remove that check.
Wow now they all are passed...all good he is getting the data and using the more better fieldnames, all working well.
Now we come to testing the PUT, Mmm data being passed but not being updated in the record, some fields are, some are not.
What the developer did was used the json record that was passed in the get to update with his data changes.
BUT WAIT!! he updates HIS_NEW_FIELDNAME (<21>) with 1234 and in the json there is MY_OLD_FIELDNAME (<21>) with null.
Bugger!
Mmm so there was a reason Don this, I should have asked.
So of cause I have changed it back and given him an abridged list of field names that he can only use.
I had a few legacy dict fieldname that were not very 'descriptive' to an outside, so I created more a more descriptive field name for the web guy to use.
Of cause these were not Master fields.
These fields were not getting thru on the GET.
In resource_services it checks for the master flag and only passes those through. Ok don was being a bit neat and tidy I thought, so bugger that, I will remove that check.
Wow now they all are passed...all good he is getting the data and using the more better fieldnames, all working well.
Now we come to testing the PUT, Mmm data being passed but not being updated in the record, some fields are, some are not.
What the developer did was used the json record that was passed in the get to update with his data changes.
BUT WAIT!! he updates HIS_NEW_FIELDNAME (<21>) with 1234 and in the json there is MY_OLD_FIELDNAME (<21>) with null.
Bugger!
Mmm so there was a reason Don this, I should have asked.
So of cause I have changed it back and given him an abridged list of field names that he can only use.
Comments
I'm not sure I detected an actual question in there, but it seems as if you are curious as to why the GetColumnNames service checks for a Master flag. Well, your situation is exactly why. I actually document the reason in the service comment block: Remember, the GetColumnNames service is used by the GetDatabaseItem service as a convenient way to get the whole datarow. In order to avoid duplicate data coming from synonyms, I opted to only return master field names. That's about as safe as I could make a generic service like this.
I should point out again that HTTP_Resource_Services was designed to be an "application service module that provides simple CRUD operations for resources that map directly to database tables". Its original purpose was to provide you and other customers a starting point by which to develop web APIs. I did not intend for it to be used as a mainstream utility, but oddly enough it as become used quite frequently as such (even by me).