DataProtocol PUT/PATCH: use parametes in URL and body

[kiipper]

Hi, I am trying to integrate SmartClient DataSource with PostREST (https://postgrest.org/).
Using transformRequest we made it work for "fetch" operations.
So far, so good. In fact it's really good, because once the

DataSource.dataFormat: "json"

is set, SmartClient handle everything. ;)

Reading the documentation (https://smartclient.com/smartclient-...pe..DSProtocol) we got this nice example:

operationBindings:[
       {operationType:"fetch", dataProtocol:"getParams"},
       {operationType:"add", dataProtocol:"postParams"},
       {operationType:"remove", dataProtocol:"getParams", requestProperties:{httpMethod:"DELETE"}},
       {operationType:"update", dataProtocol:"postParams", requestProperties:{httpMethod:"PUT"}}
    ],

Valid values:

"getParams" Data is added to the dataURL, with each property in the data becoming an HTTP parameter, eg http://service.com/search?keyword=foo
"postParams" Data is POST'd to the dataURL, with each property becoming an HTTP parameter, exactly as an HTML form would submit them if it had one input field per property in the data.

Now we have to make it work with httpMethod:PUT for "update" operations, but then there's a catch.
The REST is expecting that, some parameters will be send in the URL (like getParams), and other parameters must be sent in the body (like postParams).
Like this (https://postgrest.org/en/v12/referen...ws.html#update):

curl "http://localhost/employees?id=eq.4" \
  -X PUT -H "Content-Type: application/json" \
  -d '{ "id": 4, "name": "Sara B.", "salary": 60000 }'

How should we proceed?
Is there a way to inject the json data in the body, or to change the dataURL, from inside the transformRequest method?

Thank you for any help.
By the way, we're using v12.1p_2024-03-19/PowerEdition

[Isomorphic]

A simple way to do this is just to change DSRequest.dataURL in transformRequest(). Did you consider that possibility, and find a reason it wouldn't work for you?

Just a further note that SmartClient already includes a full CRUD integration with Postgres that is substantially more powerful and more capable than what you are considering integration with here. So, you could just skip a great deal of work and have something quite a bit better (queuing, calculated fields, SQL templating - it's a long list of advantages).

The only reason we would consider PostgREST would be a kind of "serverless" architecture where you will have the browser connecting directly to Postgres, with no server layer of any kind in between. There are *severe* disadvantages this kind of architecture for a typical enterprise app (such as: zero access to any business logic libraries other than the limited set directly supported by Postgres!), so it would only be suitable for a very unusual set of requirements!

[kiipper]

Yup, we considered changing DSRequest.dataURL.
But dataURL property is not there (https://smartclient.com/smartclient-...tr..RPCRequest).

Would this be right? (I do not thing it will work, neither it's intended to be like this)

transformRequest: function (dsRequest) {
  dsRequest["dataURL"] = "https://someplace/somewhere/?over_the=rainbow"

 //... code here
}

We also tried DSRequest.actionURL, with no results.

You got it right: We wanted to go "serverless", yet SmartClient interface is too good to change.
By the way, I already use SmartClient-Power Server, since 2014 (maybe more).
But, as the years go by, it's getting harder to find java developers. Also tomcat+database requires some maintenance.
In fact, I've stopped to use SmartGWT (Java Client) and migrate to SmartClient (javascript).
It's working good, got a better code performance, no more GWT compile, faster debug too.
There are several other factors, but it's not the point of this thread.

I liked to see how isomorphic is growing into react and angular. :cool:

[Isomorphic]

Sorry for the confusion. "dataURL" is the property on DataSource, but at this phase in processing, you are looking to set dsRequest.actionURL, a property inherited from rpcRequest.

As far as the planned migration to Postgrest, it really doesn't seem to make sense. Consider:

1) if you are using the SmartClient server, if you sole thing you write is a series of single-line .ds.xml files with autoDeriveSchema, and you have absolutely no other code or configuration, you already have vastly superior capabilities relative to direct use of Postgrest. In particular, Queuing is a huge deal, and not having it will make your app a lot slower.

2) starting from that baseline, many of the things you might want to do (bits of business logic) will be concise and simple declarations added to your .ds.xml. It's going to be much less to maintain and much simpler than with Postgrest.

3) if you have situations where you want to write some server code, you can use our Server Scripting to write them in whatever language

4) we're not sure where you're looking for Java developers, but they are still easy to find - much much easier to find than developers who can write business logic for Postgres!

Note this is the tip of the iceberg. The situation is such that, the longer we think about it, the more we think of serious flaws and drawbacks.