Petals BC REST

We should be able to generate fault on HTTP codes different from 20x

Details

  • Type: Improvement Request Improvement Request
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.0.1-BC
  • Fix Version/s: 1.1.0-BC
  • Component/s: Provider mode
  • Security Level: Public
  • Description:
    Hide

    On provider side, now the HTTP codes different from 20x are transformed into JBI errors. We should be able to generate fault on HTTP codes that have such a meaning.

    When receiving an answer to an HTTP Request, depending on the code, it is possible to define a transformation to apply to the returned content.

    <rest:mapping>
       ...
       <rest:operation name="ged:consulter">
          ...
          <rest:on-http-status code="404">
             <rest:xsl as-fault="true">404.xsl</rest:xsl>
          </rest:on-http-status>
          ...
       </rest:operation>
       ...
    </rest:mapping>

    Where:

    • on-http-status defines the processing to apply when the HTTP code given by the attribute 'code' is returned,
    • xsl defines the XSL to execute on the given HTTP code. The XSL transformation result will be returned as fault or normal response according to the attribute 'as-fault',
    • Note:
      • for MEP 'RobustInOnly', the XSL transformation result will be returned as fault only because the pattern does not support normal response. A warning will be logged if the configuration defines to generate a normal response.
      • for MEP 'InOnly', no XSL transformation is needed. When receiving a HTTP code different from 20x, if a configuration 'on-http-status' exists for it, the status DONE will be returned, otherwise the status ERROR.

    If there is no 'on-http-status' configuration:

    • 2XX: normal response (status DONE for InOnly and RobustInOnly, and response content as Out for InOut and InOptOut)
    • Error for all other HTTP Code (with the error and the reason in the message)
    Show
    On provider side, now the HTTP codes different from 20x are transformed into JBI errors. We should be able to generate fault on HTTP codes that have such a meaning. When receiving an answer to an HTTP Request, depending on the code, it is possible to define a transformation to apply to the returned content.
    <rest:mapping>
       ...
       <rest:operation name="ged:consulter">
          ...
          <rest:on-http-status code="404">
             <rest:xsl as-fault="true">404.xsl</rest:xsl>
          </rest:on-http-status>
          ...
       </rest:operation>
       ...
    </rest:mapping>
    Where:
    • on-http-status defines the processing to apply when the HTTP code given by the attribute 'code' is returned,
    • xsl defines the XSL to execute on the given HTTP code. The XSL transformation result will be returned as fault or normal response according to the attribute 'as-fault',
    • Note:
      • for MEP 'RobustInOnly', the XSL transformation result will be returned as fault only because the pattern does not support normal response. A warning will be logged if the configuration defines to generate a normal response.
      • for MEP 'InOnly', no XSL transformation is needed. When receiving a HTTP code different from 20x, if a configuration 'on-http-status' exists for it, the status DONE will be returned, otherwise the status ERROR.
    If there is no 'on-http-status' configuration:
    • 2XX: normal response (status DONE for InOnly and RobustInOnly, and response content as Out for InOut and InOptOut)
    • Error for all other HTTP Code (with the error and the reason in the message)
  • Environment:
    -

Issue Links

Activity

Hide
Victor NOËL added a comment - Wed, 25 Jan 2017 - 16:41:47 +0100

reopen, missing documentation

Show
Victor NOËL added a comment - Wed, 25 Jan 2017 - 16:41:47 +0100 reopen, missing documentation
Hide
Victor NOËL added a comment - Thu, 26 Jan 2017 - 11:45:31 +0100

documentation is up to date

Show
Victor NOËL added a comment - Thu, 26 Jan 2017 - 11:45:31 +0100 documentation is up to date

People

Dates

  • Created:
    Wed, 25 Jan 2017 - 16:34:26 +0100
    Updated:
    Thu, 26 Jan 2017 - 11:45:31 +0100
    Resolved:
    Thu, 26 Jan 2017 - 11:45:31 +0100