A standard REST API - ODATA? - Forum - OpenEdge Development - Progress Community
 Forum

A standard REST API - ODATA?

This question is not answered

I recently attended the Kendo UI Builder 2.0 webinar (many thanks for this). It was mentioned that there is limited read ODATA support. Is this supported in OpenEdge via a new version of the JSDO?

What are the plans for extending ODATA to CRUD, etc?

We are looking at building a standard REST API to expose our application and REST seems to be more a series of guidelines and good practice rather than a fixed standard, eg. filtering, paging, etc.

Any thoughts appreciated.

All Replies
  • Thanks for mentioning ODATA, I've not really looked into it previoiusly and it's worth a look as we are in the same position in respect of being ready to start building a REST API on top of our ERP solution.

    I've been more focused at looking at RAML and Swagger as potential products to be used for documenting any API, so would be interested in knowing if Progress are going to be doing anyhting in this area?

    Can see two possible directions of integration;

    1 - Can a Openedge REST API (e.g. Webspeed web handler) be parsed and the maching Swagger or RAML generated ?

    2 - Can we parse a Swagger or RAML definition and generate a Openedge handler stub, including matching prodataset definition etc. ?

    I'd also be interested in knowing if you are going to be using Openedge REST or Openedge Webspeed handlers for implementing your API's? The latter Webspeed route seems to be much lighter config wise with no downsides ?

  • We are using WebHandlers so that we can use all the REST verbs such as Patch. Only downside is it will take us longer to generate generic coding as a Class than using procedural.

  • Are you saying OO coding is taking you longer thran procedural coding? That’s hard to believe!
     
    But if you think so, the Web Handler would only need to be the first bit of code called from the web. From there on you can continue to remain in the past and write procedures.
     
    Von: carl.williams [mailto:bounce-carlwilliams@community.progress.com]
    Gesendet: Dienstag, 25. Juli 2017 14:04
    An: TU.OE.Development@community.progress.com
    Betreff: RE: [Technical Users - OE Development] A standard REST API - ODATA?
     
    Update from Progress Community
     

    We are using WebHandlers so that we can use all the REST verbs such as Patch. Only downside is it will take us longer to generate generic coding as a Class than using procedural.

    View online

     

    You received this notification because you subscribed to the forum.  To unsubscribe from only this thread, go here.

    Flag this post as spam/abuse.

     

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • It takes longer as I have not used Eclipse much or OO much so I have a learning curve. It took me 3 hours this morning to get the environment setup in the first place. I am not saying OO is slower in general but it is when you have to get up to speed.

  • “Most” (or many, or some, depending on who you talk to)  people seem to be headed down the Swagger or OpenAPI route (rather than RAML).  I think both directions you mention would be interesting  - Swagger has a “codegen” module which  can easily be extended to add either webhandlers or DataObjectHandler mapping files.
     
    Also, currently the “Mapped Data Object Services” use annotations in ABL to generate a Data Services Catalog which is similar to a Swagger doc is you squint a little. Obviously this would need extension/work to be fully Swagger compliant.
     
  • Thanks Peter.

    I know that Mike Fechner / SmartComponents has been working on a Swagger / Business Entity integration which I will be looking into shortly. The ideal from my point of view would be Swagger generates the webhandlers and then roundtips changes to the webhandlers and any annotations.

    For a public API a self-generating document is very appealing, with the ability to run sample requests and use codegen then to generate the client side to consume the endpoints.