Hello Everyone, I want to use sessions in glue APIs, Is there any way to have that??

U040LMJF6TY

Hello Everyone,
I want to use sessions in glue APIs, Is there any way to have that??

Alberto Reyer

In theory you could pass the session id as a header/cookie as it is done in Yves.
But why would you do that? Glue is designed as REST/JSONAPI API, which is by definition stateless and sessions are stateful.
Maybe you can elaborate what you want to achieve, I'm sure there is a better alternative then using the session in Glue.

U040LMJF6TY

@UL6DGRULR

Here is the scenario, I have two APIs API_1 and API_2.

In an API_1 I have a request param xyz with value 123 and in API_2 I have a response param XYZ.
So if someone hit the API_1 with param xyz value 123, API_2 will populate the same value in the return response.

Alberto Reyer

And why do you need a session for that? In API_1 create a storage entry for xyz (https://github.com/spryker/storage/blob/master/src/Spryker/Client/Storage/StorageClientInterface.php#L31) and in API_2 you read the storage entry for xyz (https://github.com/spryker/storage/blob/master/src/Spryker/Client/Storage/StorageClientInterface.php#L89).
If you need a permanent storage you should instead save the value of xyz in the Zed database and either read it from their or write it to the storage at the same time for fast access.

U040LMJF6TY

But params will vary end to end for each person or device.

U040LMJF6TY

@UL6DGRULR

Alberto Reyer

you could build the storage key in a manner to include the person and device (e.g.: kv:<person>:<device>:xyz .
But I still don't get why you have one API to write and one to read for values that are bound to an individual session (person & device). In those cases it could make sense to not store the value at all in Spryker but only on the device.

fsmeier

I would also highly advice against introducing sessions to Glue. From IT architecture view this does not make sense at all to introduce sessions to a restful api imo…. I would rather work with tokens or what Alberto suggests

U040LMJF6TY

@UL6DGRULR @florian.scholz

Thanks for it, I am considering this.