REST adapter and "Item" URI's

Posted by Mike Fechner on 15-Jan-2015 07:31

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/ ) 

All Replies

Posted by Fernando Souza on 15-Jan-2015 08:06

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.

Posted by Peter Judge on 15-Jan-2015 08:20

Mike,
 
It is – or should be I checked in 11.5 - possible to use the former scheme with the REST adapter.
 
You can do the mapping as follows. First input, then  output. The code in readTable has the following signature
 
PROCEDURE readTable:
    DEFINE INPUT PARAMETER tableName    AS CHARACTER    NO-UNDO.
    DEFINE INPUT PARAMETER filter       AS CHARACTER    NO-UNDO.
    DEFINE OUTPUT PARAMETER jsonText    AS LONGCHAR     NO-UNDO.
   
The URL you call is something like  http://localhost:8980/GenericService/rest/GenericService/customer/1 . Is that what you're after?
 
 
 
-- peter
 
[collapse]
From: Mike Fechner [mailto:bounce-mikefechner@community.progress.com]
Sent: Thursday, 15 January, 2015 08:32
To: TU.OE.Development@community.progress.com
Subject: [Technical Users - OE Development] REST adapter and "Item" URI's
 
Thread created by Mike Fechner

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/

Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]

Posted by egarcia on 15-Jan-2015 08:22

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.

Posted by Mike Fechner on 15-Jan-2015 08:58

That works like a charm! Thanks to all of you!!!
 
However in 11.4 there seems to be a limitation, that I cannot export the same ABL method twice in the form:
 
…./Customer/42
 
and
 
…./Customer?CustNum=42
 
When I design the Interface like that, I get the following error, when publishing that to the REST Adapter.
 
Unable to generate PAAR file(s).
method name 'Consultingwerk.Samples.Rest.Customer..GetRequest' is duplicate

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?

 

 

Posted by Peter Judge on 15-Jan-2015 09:31

> http://server:port/CustomerRest/rest/CustomerRest/v2/Customer                   ->   NewCustomerCode
> http://server:port/CustomerRest/rest/CustomerRest/latest/Customer            ->   NewCustomerCode

I can't comment on whether that error is by design or not (though it seems kinda odd).
 
I would be tempted to do the ../latest/... to .../v2/... redirection in the webserver; however, Tomcat 7 doesn't provide native rewrite functionality (there's a valve for it in Tomcat 8 though). Similarly, you could do the ../Customer?CustNum=x to ../Customer/x rewrite there too.
 
Another alternative might be to pass the version in as another argument to a dispatching service interface, and have that make the relevant call.
 
-- peter
 
 
 
[collapse]
From: Mike Fechner [mailto:bounce-mikefechner@community.progress.com]
Sent: Thursday, 15 January, 2015 09:59
To: TU.OE.Development@community.progress.com
Subject: [Technical Users - OE Development] AW: REST adapter and "Item" URI's
 
Reply by Mike Fechner
That works like a charm! Thanks to all of you!!!
 
However in 11.4 there seems to be a limitation, that I cannot export the same ABL method twice in the form:
 
…./Customer/42
 
and
 
…./Customer?CustNum=42
 
When I design the Interface like that, I get the following error, when publishing that to the REST Adapter.
 
Unable to generate PAAR file(s).
method name 'Consultingwerk.Samples.Rest.Customer..GetRequest' is duplicate

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?

 

 

Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]

Posted by Mike Fechner on 15-Jan-2015 11:19

“I can't comment on whether that error is by design or not (though it seems kinda odd).”
 
And I can hardly think of a technical requirement for that. Maybe someone that made this design decision could shed some light.
 
“I would be tempted to do the ../latest/... to .../v2/... redirection in the webserver;”
 
Thought of that too. But keeping it in the REST service definition means it’s all in one place.
 
“Another alternative might be to pass the version in as another argument to a dispatching service interface, and have that make the relevant call.”
 
We are looking into that as well (see my other thread from this morning).
 

Posted by Michael Jacobs on 15-Jan-2015 12:13

Hi Mike,

The implementation appears to be:  1 URI & verb == 1 REST resource == 1 procedure/class:method

/CustomerRest/{custVers}/Customer    

Posted by Mike Fechner on 15-Jan-2015 13:47

Hi Mike,

/CustomerRest/{custVers}/Customer    

That looks promising!

Posted by Mike Fechner on 16-Jan-2015 02:39

[quote user="Michael Jacobs"]

/CustomerRest/{custVers}/Customer    

[/quote]
Works fine - thanks, Mike - and will probably be enough for us right now!
[quote user="Michael Jacobs"]

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.

Posted by Michael Jacobs on 16-Jan-2015 05:31


I had asked that same question because I wanted to map a number of REST resources to the same ABL service interface handler.  The response was that there was an issue.    The workaround I found was to use a number of URL variables and a Singleton remote class as a service interface that used copious methods with minor name changes that all simply called the same base class method.  If you real ABL guys can suggest a better way I'd be interested?

Mike J.

[collapse]
From: Mike Fechner <bounce-mikefechner@community.progress.com>
Reply-To: "TU.OE.Development@community.progress.com" <TU.OE.Development@community.progress.com>
Date: Friday, January 16, 2015 at 3:40 AM
To: "TU.OE.Development@community.progress.com" <TU.OE.Development@community.progress.com>
Subject: RE: [Technical Users - OE Development] REST adapter and "Item" URI's

Reply by Mike Fechner

Michael Jacobs

/CustomerRest/{custVers}/Customer    

Works fine - thanks, Mike - and will probably be enough for us right now!
Michael Jacobs

The 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.

[/collapse]

Posted by Mike Fechner on 16-Jan-2015 05:42

Hi Mike, I was considering for a similar workaround, by inheriting from the „real“ class, so that the PUBLIC method of the child class is actually just a second reference to the method from the real class.
 
But I like your earlier suggestion with the …/CustomerService/{version}/Customer/ much better J
 
Von: Michael Jacobs [mailto:bounce-mjacobs@community.progress.com]
Gesendet: Freitag, 16.
Januar 2015 12:32
An: TU.OE.Development@community.progress.com
Betreff: Re: [Technical Users - OE Development] REST adapter and "Item" URI's
 
Reply by Michael Jacobs
 
I had asked that same question because I wanted to map a number of REST resources to the same ABL service interface handler.  The response was that there was an issue.    The workaround I found was to use a number of URL variables and a Singleton remote class as a service interface that used copious methods with minor name changes that all simply called the same base class method.  If you real ABL guys can suggest a better way I'd be interested?
 
Mike J.
 
[collapse]
From: Mike Fechner <bounce-mikefechner@community.progress.com>
Reply-To: "
TU.OE.Development@community.progress.com" <TU.OE.Development@community.progress.com>
Date: Friday, January 16, 2015 at 3:40 AM
To: "
TU.OE.Development@community.progress.com" <TU.OE.Development@community.progress.com>
Subject: RE: [Technical Users - OE Development] REST adapter and "Item" URI's
 
Reply by Mike Fechner
Michael Jacobs
/CustomerRest/{custVers}/Customer    
Works fine - thanks, Mike - and will probably be enough for us right now!
Michael Jacobs
The 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.

Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]

This thread is closed