Differences between revisions 6 and 7
Revision 6 as of 2015-01-20 08:33:04
Size: 5547
Editor: MichaelBolz
Comment:
Revision 7 as of 2015-01-20 08:47:34
Size: 5715
Editor: MichaelBolz
Comment:
Deletions are marked like this. Additions are marked like this.
Line 9: Line 9:
According to above exception are the Action*Processor interfaces which extends their according processor based on the ReturnType of the action (e.g. an ActionEntityProcessor extends the EntityProcessor). With this decision it is possible to implement ActionImports support independent to base e.g. Entity support. According to above exception are the Action*Processor interfaces which extends their according processor based on the ReturnType of the action (e.g. an ActionEntityProcessor extends the EntityProcessor). With this decision for a separate interface it is possible for an implementation to only support e.g. basic Entity (read/update/delete/create) support without implementing a (inherited) processActionEntity(..) with e.g. then just a throw a new UnsupportedOperationException(..).

General concept

Leading concept behind the processor interfaces is the ReturnType which is handled by the OData request. As an example a request to the URL ../service/EntityCollection would be handled by the EntityCollectionProcessor and a request to ../service/EntityCollection(myKeyValue) would be handled by the EntityProcessor.

According to this concept for each ReturnType exists (at least) an own *Processor interface with the according method for each (defined by OData-Specification) possible HTTP requests (see chapter: Mapping HTTP Request -> Processor Method).

An exception to this are the MediaEntityProcessor and PrimitiveValueProcessor which extends other base interfaces (EntityProcessor <- MediaEntityProcessor and PrimitiveValueProcessor <- PrimitiveValueProcessor). Both cases are based on the fact that the base and the extended interface are only different in one (or two) method and this method is an extension to the base interface functionality. So that a MediaEntityProcessor must implement all methods of the EntityProcessor to support the base entity functions as well as its own extension method to support the media functionality. According to above exception are the Action*Processor interfaces which extends their according processor based on the ReturnType of the action (e.g. an ActionEntityProcessor extends the EntityProcessor). With this decision for a separate interface it is possible for an implementation to only support e.g. basic Entity (read/update/delete/create) support without implementing a (inherited) processActionEntity(..) with e.g. then just a throw a new UnsupportedOperationException(..).

A further exception are the three Count*CollectionProcessor interfaces. Based on the concept of ReturnTypes all processor interfaces delivers just the count as a number. However for an implementation it could be from interest which type of collection has to be counted (e.g. Entity, Primitive, Complex) hence for each OData-EntityCollection exists an own interface.

For the general mapping of HTTP request to according interface method exists exceptions for ErrorProcessor, BatchProcessor and all Action*Processor interfaces. Those interfaces all have a processXX(…) method which handles the according request.

Processor Interfaces

Processor methods

General method signature

General method signature is that the method name is a combination of the type of request (create/read/update/delete) and the to be handled EDM-Type (e.g. Entity or EntityCollection or …). Only exception are the process methods of the BatchProcessor (processBatch(...)), ErrorProcessor (processError(...)) and all Action*Processor (e.g. processActionEntity(...) ). Because for this methods exists no direct mapping of the request type to an according create/read/update/delete.

Each method has following parameters: the Request as request:ODataRequest parameter, the response as response:ODataResponse parameter and the informationen for the request URI as uriInfo:UriInfo parameter. Because the response for a request is also given as a parameter all methods does not have a return value (i.e. all are "void"). This architectural decision is inspired by the JavaEE-Servlet architecture (javax.servlet.*).

Additional to listed parameters each method for which the response format is dependent on the HTTP Accept Header or OData $format option has the responseFormat:ContentType parameter which defines the content type after the content negotiation for the response.

Additional to listed parameters each method for which the request contains a body part (e.g. POST/PUT requests) has the requestFormat:ContentType parameter which is the HTTP Content-Type header for the request.

General HTTP request to Processor method mapping

  • HTTP GET -> readXxx(...) (example for Entity:

    • readEntity(request:ODataRequest, response:ODataResponse, uriInfo:UriInfo, responseFormat:ContentType):void

  • HTTP POST -> createXxx(...) (example for Entity:

  • HTTP PUT / PATCH -> updateXxx(...) (example for Entity:

  • HTTP DELETE -> deleteXxx(...) (example for Entity:

    • deleteEntity(request:ODataRequest, response:ODataResponse, info:UriInfo):void

Class diagram

Processor Interfaces

Class-Diagram-ProcessorInterfaces.png

Class-Diagram-ProcessorInterfaces.png

URI Info Interfaces

UriInfo-ClassDiagram.png

UriInfo-ClassDiagram.png

Documentation/ProcessorInterfaces (last edited 2015-01-20 08:47:34 by MichaelBolz)