Hi, a common scheme for REST servers is to adress "records" using their unique key value as the URI and not just as a query string parameter.
http://server:port/Sports2000Rest/rest/Sports2000Rest/Customer/42
vs.
http://server:port/Sports2000Rest/rest/Sports2000Rest/Customer?CustNum=42
The second scheme (using the query string parameter) can be modelled using the REST adapter.
Is seems that we are not able to model the first scheme.
When trying to access the "Customer" resource that way, Tomcat replies with an http 404 error.
(public sample found on stackoverflow: http://www.thomas-bayer.com/sqlrest/CUSTOMER/3/ )
You should be able to model either one. But you have to define the proper URI for that resource. How did you define the URI? You would have to define it something like "/Customer/{CustNum}", and then map the the CustNum from the URI to some parameter in your Business Entity.
Hi, a common scheme for REST servers is to adress "records" using their unique key value as the URI and not just as a query string parameter.
http://server:port/Sports2000Rest/rest/Sports2000Rest/Customer/42
vs.
http://server:port/Sports2000Rest/rest/Sports2000Rest/Customer?CustNum=42
The second scheme (using the query string parameter) can be modelled using the REST adapter.
Is seems that we are not able to model the first scheme.
When trying to access the "Customer" resource that way, Tomcat replies with an http 404 error.
(public sample found on stackoverflow: http://www.thomas-bayer.com/sqlrest/CUSTOMER/3/ )
Flag this post as spam/abuse.
hello Mike,
The following post has a sample program (and a video) showing how to return data for an item (element) using a REST project:
community.progress.com/.../45513.aspx
Notice that customer_rest.p returns the data as LONGCHAR so that it returns the format for only one record.
I hope this helps.
Is there any reason for this limitation or am I once more overlooking something? I cannot see a reason why the same ABL method should not be used to “fake” two resources?
I might want to use this as another approach to versioning the interfaces:
http://server:port/CustomerRest/rest/CustomerRest/v1/Customer -> OldCustomerCode
http://server:port/CustomerRest/rest/CustomerRest/v2/Customer -> NewCustomerCode
http://server:port/CustomerRest/rest/CustomerRest/latest/Customer -> NewCustomerCode
I am expecting that here I’d run into the same issue as the last two resources would share the same ABL class and methods – correct?
>
http://server:port/CustomerRest/rest/CustomerRest/v2/Customer -> NewCustomerCode
> http://server:port/CustomerRest/rest/CustomerRest/latest/Customer -> NewCustomerCode
Is there any reason for this limitation or am I once more overlooking something? I cannot see a reason why the same ABL method should not be used to “fake” two resources?
I might want to use this as another approach to versioning the interfaces:
http://server:port/CustomerRest/rest/CustomerRest/v1/Customer -> OldCustomerCode
http://server:port/CustomerRest/rest/CustomerRest/v2/Customer -> NewCustomerCode
http://server:port/CustomerRest/rest/CustomerRest/latest/Customer -> NewCustomerCode
I am expecting that here I’d run into the same issue as the last two resources would share the same ABL class and methods – correct?
Flag this post as spam/abuse.
Hi Mike,
The implementation appears to be: 1 URI & verb == 1 REST resource == 1 procedure/class:method
/CustomerRest/{custVers}/Customer
/CustomerRest/{custVers}/Customer
[quote user="Michael Jacobs"]
/CustomerRest/{custVers}/Customer
The implementation appears to be: 1 URI & verb == 1 REST resource == 1 procedure/class:method
[/quote]
I would still be interested to understand if that was done deliberately or there are technical reasons for this or we can get that "fixed" in a release to come.
[/collapse]Reply by Mike FechnerMichael Jacobs/CustomerRest/{custVers}/Customer
Works fine - thanks, Mike - and will probably be enough for us right now!Michael JacobsThe implementation appears to be: 1 URI & verb == 1 REST resource == 1 procedure/class:method
I would still be interested to understand if that was done deliberately or there are technical reasons for this or we can get that "fixed" in a release to come.
Stop receiving emails on this subject.Flag this post as spam/abuse.
Reply by Mike FechnerMichael Jacobs/CustomerRest/{custVers}/CustomerWorks fine - thanks, Mike - and will probably be enough for us right now!Michael JacobsThe implementation appears to be: 1 URI & verb == 1 REST resource == 1 procedure/class:methodI would still be interested to understand if that was done deliberately or there are technical reasons for this or we can get that "fixed" in a release to come.
Stop receiving emails on this subject.Flag this post as spam/abuse.
Flag this post as spam/abuse.