Truly RESTful REST adapter

Posted by bronco on 12-Mar-2014 14:26

Hi,

Although there's no official standard for REST API's there are some conventions. The most important being able to select for example customer number 1 like this:

https://www.sports2000.net/customer/1

And something similar for PUT & DELETE requests.

Would it be possible to realize this with the current REST adapter implementation? My assumption is that it's not possible, but over the years I've learned to verify my assumptions.

 

All Replies

Posted by Michael Jacobs on 12-Mar-2014 15:30

Would this URI work?

www.sports2000.net/.../1

If the answer is yes, then the REST adapter can be your answer.   The REST adapter allows you to highly customize the http message and URI space following the /<web-application-name>/rest/ path.

Posted by Michael Jacobs on 13-Mar-2014 05:00

I see that the software truncated the URL example from my reply.   Allow me to try this again...

I am not sure why you would assume the REST adapter would not basic use cases - but the answer is yes.  The REST adapter can handle the very basic use case you presented plus much, much, more.  You can map the URIs, http headers, http cookies, and http body with almost all of the OpenEdge datatypes you can pass to a remote procedure.   The only requirement is that the URL's path needs to include the web application [context] name and the relative path 'rest'.    The former is required by the Java web server the REST adapter runs in, and the latter by the default configuration of the REST adapter's servlet implementation.   The remainder of the URI's path is completely at your discretion.

The adapter will support the GET, PUT, DELETE, and POST verbs and JSON encoding.    Which combination your application exposes is up to you.

Posted by bronco on 14-Mar-2014 05:37

OK, great. My assumptions where about the CRUD functions of a business entity in a mobileservice, so I guess the post haven't been written down correctly.

If you implement them as a separate REST service you would loose the advantages of the JSDO/catalog. It would be great if both the REST & Mobile services could be utilized by the same uniform RESTful api. Saves the developer of building extra code to achieve the same thing twice.

Posted by Bill Wood on 14-Mar-2014 06:29

As you pointed out when you started the thread "there's no official standard for REST API's".

When OE Mobile made design choices there where questions about how much to go for the lowest common denominator of REST (which would give no advantage to the JSDO over the "original" MAB REST services), vs taking advantage of the fact that the backend was OpenEdge services with prodatasets.    The current approach allows for things like batch updates/deletes, create/update that enrich the result (auto-sequence fields, etc), and future extensions into complex datasets and before-imaging support.

But this is a good discussion to continue.

Posted by Michael Jacobs on 14-Mar-2014 07:10

I agree wholeheartedly.  The JSDOs provide great value for applications whose primarily use-case is CRUD operations and RPC like remote calls.   Like SOAP, the properties of the transport the JSDOs uses are hidden so the application code is not bound to any single transport type such as http.   The initial rollout of JSDOs chose to tunnel through RESTful http (i.e. the REST adapter) because it provided the best value for the greatest number of use-cases.  Doesn't mean that http is the only transport that will ever be used between your mobile device and the AppServer's service interface.

There are use cases when using true RESTful communications is the right thing to do because your AppServer ABL application wants/needs to take low level control of the http transport's properties.   That is where the REST adapter's full feature set is useful because it allows your AppServer direct access to most aspects of http via parameters in ABL procedures and class methods.   But there are limitations in that the client must communicate directly with the AppServer with only a web server (REST adapter) in the middle.

There is nothing stopping you from creating a Mobile project that employes both Mobile and RESTful service interfaces, if that is truly necessary.   The majority of the time it not necessary.  You just cannot combine the features of both into the same API (today).

Posted by Marian Edu on 15-Mar-2014 01:20

While it's true there is no standard for REST but for basic CRUD there is a `work in progress`, let's pick up a link from progress realm that explains a bit the idea behind - blogs.datadirect.com/.../the-future-of-web-based-data-access-odata.html.

Truth is Data Direct is naturally interested to have standards while the vendors might be tempted more to adopt proprietary extensions :(

odata4j have a working implementation for jdbc producer, couple that with a jdbc driver that can talk 4gl - like 'abl jdbc' ;) and you're all set

Posted by Bill Wood on 15-Mar-2014 05:28

And that is why mobile is currently looking at OData.... But while you can point to this spec today, remember that the design of this was from 2012 and OData was even further away from being a standard then that it is now.

I think you will find that there are (intensional) similarities between OE Mobile REST and OData. But there are differences - some due to the timing and state of the spec in 2012 and some due to wanting to optimize for ABL. (An obvious one would be that an OData $filter query parameter is not identical to an ABL where clause, and having an OpenEdge mobile service you probably want the ABL clause ).

You will also find that OData is a use of REST but is also restrictive so to the original post requiring OData would not solve your original requirement of supporting any REST client.

Look for more on OData with Progress in the future. =

This thread is closed