0

I'm designing a system that will

  • Act as proxy calling a service on a back-end in context of user and his session
  • Manage sessions for users on multiple back-ends

I will expose the system over HTTP.

Most of the requests will need back-end-id, user-id and session-id parameters, now I can model it as path parameters

/:back-end-id/:user-id/:session-id/...

Or as HTTP headers (x-agrzes-back-end-id, x-agrzes-session-id, x-agrzes-user-id)

Where it is better to put those parameters?

For proxy endpoints I definitely not want them in body or query as I want to forward them as is to back-end.

The API will be used server-to-server.

The meaning of session may be something like OAuth authorization. The system manages obtaining and renewing of access credentials and then transparently allows to access back end resources using those credentials.

So example exchange might look like this

  • Establish session foo for user bar with back end bazz
  • < OAuth exhacnge managed and guided by the system >
  • Call service A on back end bazz in the context of user bar and his session foo (works if the session is established and credentials are valid)

The session identifier is chosen by the client so while all three (session id, user id, session id) are needed to find the session the client does not have to store generated session identifiers so can be stateless.

AGrzes
  • 379
  • 2
  • 9

2 Answers2

3

URLs should identify resources. So this depends on the semantics of your requests.

I would go neither way, but one in between. Without knowing you exact use cases, I'd argue that the backend-id and the user-id are properties of the resource you are requesting, hence they should be part of the resource identifier.

At the other hand the session-id is rather a boundary condition and not really a property of the resource. It's more of a property of the request. The session may or may not change, but the resource does not, it is invariant towards the session. Hence I'd argue, that the session-id should not be a part of the resource identifier, but rather be a header.

If the user-id is not considered a part of the resource, but rather used for authorization purposes (disregarding the fact that this might be a very bad idea), it might go better in the header and vice versa if the session-id is considered a part of the resource for whatever reason.

amon
  • 132,749
  • 27
  • 279
  • 375
Paul Kertscher
  • 2,434
  • 1
  • 15
  • 20
  • For the proxy endpoint (family) is hard to talk about resources as proxied services can use various standards and semantics (or none at all except of use of HTTP protocol). user-id meaning is "act in the name of user" - assuming callers of the service are trusted (or authorized other way). – AGrzes Oct 24 '18 at 13:43
0

It looks like you are trying to send stateful data via a stateless protocol. destination pain!

In most cases you would expect the session id to be specific to the user and backend. It would also be generated by the proxy rather than the client.

Given this I would have the client start the session with an Open(userid, backendid? (possibly generated by proxy)) request and add the session id to the reply as a cookie, keeping the related userid and backend id stored on the proxy.

The client can then send the session id cookie with its subsequent requests and have the proxy pull out the matching userid and backend from its internal store

Ewan
  • 70,664
  • 5
  • 76
  • 161