Designing a Pragmatic RESTful API
vinaysahni.com
Designing a Pragmatic RESTful API
1–10 of 139 posts
Re: Designing a Pragmatic RESTful API
#2RESTful: almost correct usage of HTTP verbs to implement something that has nothing to do with REST. But it sure sounds nice.
Re: Designing a Pragmatic RESTful API
#3"A RESTful API should be stateless. This means that request authentication should not depend on cookies or sessions. Instead, each request should come with some sort authentication credentials."
Doesn't that mean you need to do a database lookup to verify the user with every request? Seems like a lot of overhead just for the sake of avoiding sessions.
Re: Designing a Pragmatic RESTful API
#4"A RESTful API should be stateless. This means that request authentication should not depend on cookies or sessions. Instead, each request should come with some sort authentication credentials." Doesn't that mean you need to do a database lookup to verify the user with every request? Seems like a lot of overhead just for the sake of avoiding sessions.
You don't need to do a database look up if you stuff some context into your token and encrypt it with a secret key.
When the server receives the request it can simply decrypt the token and deserialize it into some sort of strongly typed usercontext.
Re: Designing a Pragmatic RESTful API
#5"A RESTful API should be stateless. This means that request authentication should not depend on cookies or sessions. Instead, each request should come with some sort authentication credentials." Doesn't that mean you need to do a database lookup to verify the user with every request? Seems like a lot of overhead just for the sake of avoiding sessions.
Assuming you are using a distributed architecture, there is no way to verify a user without at least one database lookup because the request could be coming into any API server. So in most cases we're not avoiding cookies and sessions just for the sake of it.
Re: Designing a Pragmatic RESTful API
#6"A RESTful API should be stateless. This means that request authentication should not depend on cookies or sessions. Instead, each request should come with some sort authentication credentials." Doesn't that mean you need to do a database lookup to verify the user with every request? Seems like a lot of overhead just for the sake of avoiding sessions.
Use redis/memcache to avoid constant DB hits.
Alternatively, if a time limited token is practical, use a self-signed expiring token.
One reason to avoid sessions is security aspect of it. Cookies are handled automatically by the browser which opens the API up to XSS
Re: Designing a Pragmatic RESTful API
#7"A RESTful API should be stateless. This means that request authentication should not depend on cookies or sessions. Instead, each request should come with some sort authentication credentials." Doesn't that mean you need to do a database lookup to verify the user with every request? Seems like a lot of overhead just for the sake of avoiding sessions.
Others have already commented, but also keep in mind that subsequent requests should be pulling from cache. So the overhead is lighter than a full DB request.
Re: Designing a Pragmatic RESTful API
#8"A RESTful API should be stateless. This means that request authentication should not depend on cookies or sessions. Instead, each request should come with some sort authentication credentials." Doesn't that mean you need to do a database lookup to verify the user with every request? Seems like a lot of overhead just for the sake of avoiding sessions.
Assuming you are using a distributed architecture, there is no way to verify a user without at least one database lookup because the request could be coming into any API server. So in most cases we're not avoiding cookies and sessions just for the sake of it.
You don't need to do a database look up if you stuff some context into your token and encrypt it with a secret key.
When the server receives the request it can simply decrypt the token and deserialize it into some sort of strongly typed usercontext
Re: Designing a Pragmatic RESTful API
#9Earlier quoted context omitted.
Assuming you are using a distributed architecture, there is no way to verify a user without at least one database lookup because the request could be coming into any API server. So in most cases we're not avoiding cookies and sessions just for the sake of it.
You don't need to do a database look up if you stuff some context into your token and encrypt it with a secret key. When the server receives the request it can simply decrypt the token and deserialize it into some sort of strongly typed usercontext
Doesn't this open you up to replay attacks though? Since you can't store that a token was already used..
Re: Designing a Pragmatic RESTful API
#10Just wanted to say thank you for this. I have been searching for a good article explaining the details of thinking through building an API. This really could not have come at a better time for me! Cheers!