2

I have proposed a REST API called 'getSessionState' which basically a backend API that retrieves some state info from a redis server and return to the clients.

Because the state data is kept in a Redis server, whenever a user calls the function I will extend the expiry of the redis data structure by a bit in order to avoid key miss.

A question is raised by one of my colleagues that strictly speaking it is making a change to the state. So it shouldn't be called 'getSessionState' because 'get' implies no change to the backing data.

Is it a fair comment?

If so, what will be good alternative name to getSessionState?

My team generally uses Google's API design documentation https://cloud.google.com/apis/design/ as design guideline, but I am not sure if it covers the aspect of TTL.

Improve this question
1
  • 3
    I won't consider TTL as a state of the resource. That is just implementation details. Your API should not bother about it. I think GET is just fine.
    – Nils
    Commented Mar 13, 2020 at 5:53

1 Answer 1

Reset to default
7

The data being in redis is implementation detail. It matters if state of the data changes during the request, not if just anything changes. If It was like that, turning on access log would efectively mean your get endpoints Are no longer idempotent because they append lines to access log.

Improve this answer
1
  • 1
    Exactly. Get requests are allowed to cause state changes, they just aren't allowed to represent a clients intention to have state changed, and clients are not supposed to be accountable for any state changes that occur.
    – bdsl
    Commented Mar 13, 2020 at 9:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.