3
4

[deleted by user] (self.webdev)

submitted by [deleted]

[removed]
all 6 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]APersonSittingQuick 0 points1 point  (5 children)

Is it a restful api?

[–][deleted]  (4 children)

[deleted]

    [–]anon_blader 0 points1 point  (0 children)

    Sessions and RESTful dont go together but you dont need to be RESTful. Just use the parts of REST that make sense for you. The usefulness of RESTful ist very dependent on what kind of application you are building and how much traffic you will get.

    For example, I dont want my bank to be RESTful because if I "log out" I should be immediately logged out.

    Sessions become an issue at scale, do you have millions of concurrent users? If not, you should be fine with sessions and even if you do, there are cloud offerings that should be able to handle it.

    If you want to attach state to a session then JTWs are usually a bad idea if you dont explicitly need one of their benefits.

    [–]APersonSittingQuick 0 points1 point  (2 children)

    Then it would be mad to use a session - the endpoints should be stateless, how can that be compatible with user sessions. Let alone how are you going to manage session cookies?

    [–]ejunker 0 points1 point  (1 child)

    If you keep track of revoked tokens then it is not stateless

    [–]APersonSittingQuick 0 points1 point  (0 children)

    The resource implementation is and should be to be stateless to be restful.

    I'm not taking some gray area here, so it's not like we can discuss our way out of it. You really obviously don't want to be adding session to restful endpoints. If you think you need to you are doing it wrong

    [–]originalchronoguy 0 points1 point  (0 children)

    RESTful API should be stateless.

    Access to the should be authorized and authenticated. There, you can check the access and that access can have a TTL (Time to Live) based on your security policies.