Merge pull request #321 from Accenture/221-response-codes

221 response codes

Author: mmacai

CHANGELOG.md

@@ -12,12 +12,15 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - Support publishing events consumed from [NATS](https://nats.io) topics. See the [documentation](https://accenture.github.io/reactive-interaction-gateway/docs/event-streams.html#nats) for how to get started. [#297](https://github.com/Accenture/reactive-interaction-gateway/issues/297)
 - Added validation for reverse proxy configuration. Now it crashes RIG on start when configuration is not valid or returns `400` when using REST API to update configuration. [#277](https://github.com/Accenture/reactive-interaction-gateway/issues/277)
 - Added basic distributed tracing support in [W3C Trace Context specification](https://www.w3.org/TR/trace-context/) with Jaeger and Openzipkin exporters. RIG opens a span at the API Gateway and emits trace context in Cloud Events following the [distributed tracing spec](https://github.com/cloudevents/spec/blob/v1.0/extensions/distributed-tracing.md). [#281](https://github.com/Accenture/reactive-interaction-gateway/issues/281)
+- Added possibility to set response code for `response_from` messages in reverse proxy (`kafka` and `http_async`). [#321](https://github.com/Accenture/reactive-interaction-gateway/pull/321)
+- Added new version - `v3` - for internal endpoints to support response code in the `/responses` endpoint
 
 ### Changed
 
 - Incorporated [cloudevents-ex](https://github.com/kevinbader/cloudevents-ex) to handle binary and structured modes for [Kafka protocol binding](https://github.com/cloudevents/spec/blob/v1.0/kafka-protocol-binding.md) in a proper way. This introduces some **breaking changes**:
   - Binary mode is now using `ce_` prefix for CloudEvents context attribute headers, before it was `ce-` - done according to the [Kafka protocol binding](https://github.com/cloudevents/spec/blob/v1.0/kafka-protocol-binding.md)
 - Change above affects also `"response_from": "kafka"` proxy functionality. RIG will forward to clients only Kafka body, no headers. This means, when using binary mode, clients receive only the data part, no CloudEvents context attributes.
+- Changed `response_from` handler to expect a message in binary format, **NOT** a cloud event (`kafka` and `http_async`). [#321](https://github.com/Accenture/reactive-interaction-gateway/pull/321)
 
 ### Fixed
 

config/rig_api/config.exs

@@ -45,6 +45,7 @@ config :phoenix, :serve_endpoints, true
 
 config :rig, RigApi.V1.APIs, rig_proxy: RigInboundGateway.Proxy
 config :rig, RigApi.V2.APIs, rig_proxy: RigInboundGateway.Proxy
+config :rig, RigApi.V3.APIs, rig_proxy: RigInboundGateway.Proxy
 
 config :rig, :event_filter, Rig.EventFilter
 

config/rig_api/test.exs

@@ -10,5 +10,6 @@ config :rig, RigApi.Endpoint,
 
 config :rig, RigApi.V1.APIs, rig_proxy: RigInboundGateway.ProxyMock
 config :rig, RigApi.V2.APIs, rig_proxy: RigInboundGateway.ProxyMock
+config :rig, RigApi.V3.APIs, rig_proxy: RigInboundGateway.ProxyMock
 
 config :rig, :event_filter, Rig.EventFilterMock

docs/api-gateway.md

@@ -180,9 +180,7 @@ The endpoint expects the following request format:
 ### Wait for response
 
 Sometimes it makes sense to provide a simple request-response API to something that runs asynchronously on the backend. For example, let's say there's a ticket reservation process that takes 10 seconds in total and involves three different services that communicate via message passing. For an external client, it may be simpler to wait 10 seconds for the response instead of polling for a response every other second.
-A behavior like this can be configured using an endpoints' `response_from` property. When set to `kafka`, the response to the request is not taken from the `target` (e.g., for `target` = `http` this means the backend's HTTP response is ignored), but instead it's read from a Kafka topic. In order to enable RIG to correlate the response from the topic with the original request, RIG adds a correlation ID to the request (using a query parameter in case of `target` = `http`, or backed into the produced CloudEvent otherwise). Backend services that work with the request need to include that correlation ID in their response; otherwise, RIG won't be able to forward it to the client (and times out).
-
-> In case you want to use _binary_ transport mode, make sure that `rig` extension (containing correlation ID) is prefixed with `ce_` as well.
+A behavior like this can be configured using an endpoints' `response_from` property. When set to `kafka`, the response to the request is not taken from the `target` (e.g., for `target` = `http` this means the backend's HTTP response is ignored), but instead it's read from a Kafka topic. In order to enable RIG to correlate the response from the topic with the original request, RIG adds a correlation ID to the request (using a query parameter in case of `target` = `http`, or backed into the produced CloudEvent otherwise). **Backend services that work with the request need to include that correlation ID in their response; otherwise, RIG won't be able to forward it to the client (and times out).**
 
 Configuration of such API endpoint might look like this:
 
@@ -207,26 +205,37 @@ Configuration of such API endpoint might look like this:
 
 > Note the presence of `response_from` field. This tells RIG to wait for different event with the same correlation ID.
 
-As an alternative you can set `response_from` to `http_async`. This means that correlated response has to be sent to internal `:4010/v2/responses` `POST` endpoint with a body like this:
+#### Supported combinations (`target` -> `response_from`)
+
+- HTTP -> `kafka`/`http_async`/`kinesis`
+- Kafka -> `kafka`
+- Kinesis -> **not supported**
+- Nats -> `nats`
+
+`http_async` means that correlated response has to be sent to internal `:4010/v3/responses` `POST` endpoint.
+
+#### Supported formats
+
+All `response_from` options support only binary mode.
+
+Message headers:
+
+```plaintext
+rig-correlation: "correlation_id_sent_by_rig"
+rig-response-code: "201"
+content-type: "application/json"
+```
+
+> All headers are required.
+
+Message body:
 
 ```json
 {
-  "id": "1",
-  "specversion": "0.2",
-  "source": "my-service",
-  "type": "com.example",
-  "rig": {
-    "correlation": "_id_"
-  },
-  "data": {
-    ...
-  }
-  ...
+  "foo": "bar"
 }
 ```
 
-> **NOTE:** Kinesis doesn't support `response_from` field yet.
-
 ## Auth
 
 RIG can do simple auth check for endpoints. Currently supports JWT.

lib/rig_api/router.ex

@@ -75,6 +75,32 @@ defmodule RigApi.Router do
     end
   end
 
+  scope "/v3", RigApi.V3 do
+    scope "/apis" do
+      pipe_through(:body_parser)
+      get("/", APIs, :list_apis)
+      post("/", APIs, :add_api)
+      get("/:id", APIs, :get_api_detail)
+      put("/:id", APIs, :update_api)
+      delete("/:id", APIs, :deactivate_api)
+    end
+
+    scope "/messages" do
+      post("/", Messages, :publish)
+    end
+
+    scope "/responses" do
+      pipe_through(:body_parser)
+      resources("/", Responses, only: [:create])
+    end
+
+    scope "/session-blacklist" do
+      pipe_through(:body_parser)
+      post("/", SessionBlacklist, :blacklist_session)
+      get("/:session_id", SessionBlacklist, :check_status)
+    end
+  end
+
   def swagger_info do
     %{
       info: %{

lib/rig_api/v1/responses.ex

@@ -33,7 +33,6 @@ defmodule RigApi.V1.Responses do
 
   @doc """
   Accepts message to be sent to correlated HTTP process.
-
   Note that body has to contain following field `"rig": { "correlation": "_id_" }`.
   """
   def create(conn, message) do

lib/rig_api/v2/responses.ex

@@ -33,7 +33,6 @@ defmodule RigApi.V2.Responses do
 
   @doc """
   Accepts message to be sent to correlated HTTP process.
-
   Note that body has to contain following field `"rig": { "correlation": "_id_" }`.
   """
   def create(conn, message) do