Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

keys not returned

When I do a request to my api with a search, the records are returned, but the key fields are skipped. I assume this is because of the HAL data that is being used. However, I would still like to add the ID to the result, because I want to map the json data to my objects. So it would be nice to have the ID as well.

Is this bad practise or should I just go ahead and adjust the http_resource_services?

Comments

  • I won't say this is "bad practice" but it is not completely inline with the intent of HTTP/REST design. The philosophy of the web is that you are accessing "resources" (hence, the "R" in URL). Resources are meant to be abstractions of content rather than well-defined entities (like a document, database row, etc.) Hence, the URL itself is your Key ID. While it might not map directly to your database Key ID, it is certainly a Key ID that gains access to the resource. That is why the HAL+JSON format includes the _self URLs for each item returned.

    However, there is no reason why you cannot list your Key ID column as a part of the resource response. When we built HTTP_Resource_Services, we were gong for a pure REST design. So, my recommendation is that you modify HTTP_Resource_Services (specifically the GetColumnNames service) to always include your Key ID.

    One final note: HTTP_Resource_Services was always meant to be a quick and easy way to get and set OpenInsight database content. It has certainly become a "go to" solution for many of our customers (yours truly included), but you are not bound to HTTP_Resource_Services. In fact, more complex URL requests will likely require that you write customized logic in which you will create all of the JSON yourself.
  • My two cents.

    I found the same thing and did as Don suggests here and modified http_resource_services to always return the id though I added it to getDatabaseItems.
    I second his other suggestion as well that for more complex requests it may be better to write your own routine and forego http_resource_services. I haven't actioned that one yet but certainly intend to for one particular service at least as I find myself calling http_resource_services and then rejigging the results to present them the way I want them. It was easier initially but I suspect leads to unnecessary overhead. Plus the select options for that service are becoming more and more complicated making it less suited to a generic routine.
Sign In or Register to comment.