[
https://issues.apache.org/jira/browse/OLINGO-573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramesh Reddy reassigned OLINGO-573:
-----------------------------------
Assignee: Ramesh Reddy
> Olingo-server-extension with framework like approach for request handling
> -------------------------------------------------------------------------
>
> Key: OLINGO-573
> URL: https://issues.apache.org/jira/browse/OLINGO-573
> Project: Olingo
> Issue Type: New Feature
> Components: odata4-server
> Affects Versions: (Java) V4 4.0.0-beta-02
> Reporter: Michael Bolz
> Assignee: Ramesh Reddy
>
> Dear Community,
> Based on some discussions on OLINGO-482, there were several discussions
> merits of the Processor interface design and how it can be improved for sake
> of the service developer. Based on those discussions, I have implemented an
> alternative server side framework as extension. I added this in a separate
> branch called " olingo-server-extension" , you can also find it at
> [GitHub|https://github.com/apache/olingo-odata4/tree/olingo-server-extension]
> - This framework currently does not remove any previous Processor interfaces.
> As extension, these can be evaluated side by side for comparison, then we can
> decide on the direction best for Olingo in integrating into one module.
> - This framework designed specially to make the job of service developer as
> easy as possible to develop a OData service in the quickest time.
> - Tries to enforce the odata specification rules, where they need to be,
> before service implementer receives the request for processing
> - Moves Context URL processing away from service implementer
> - Automatically works with registered serializers based on the "Content-Type"
> defined on the request
> - Makes the building of response, based on request, such that it reflects the
> context of the request. Thus eliminates service implementer violating the
> spec expectations.
> - Provides $metadata schema parser in server side, using which a service
> implementer can "define" their metadata of the service, rather than current
> method using the object form.
> - Provides a full example based on TripPin service.
> I encourage you take look at the example service in the test section of this
> module and see how a sample service can be developed. We are looking for your
> comments and suggestions to improve upon this framework and your support of
> the design to carry forward. Please do reply, even that is either a +1 or -1
> I understand that in this new framework, there single interface called
> "ServiceHandler" for service implementer to develop along with metadata. *If*
> multiple Processor interfaces is something we really do need, it is fairly
> straight forward and *easy* to extend the requests to use multiple interfaces
> as it is currently designed, so that any existing implementations are not
> broken.
> Please take an hour or two looking through this and provide your feedback,
> and suggestions to improve upon. I sincerely appreciate your time.
> Thanks.
> Ramesh..
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
