Managing State in a Stateless API

Question

There are a lot of good resources for REST API's here on SO, and I've read dozens of them. That being said, I need some help figuring out how to manage state correctly.

I have a REST API and then an application which accesses it (via cURL and AJAX). Although not terribly important, both are written with the Laravel Framework. The application does not have any direct database interactions, everything is done through the API.

Using a common blog example (fictional), lets say I have a user logged in via OAuth and they want to add a tag to a blog post. I need to post the following information to the API endpoint:

- Access Token (User ID is retrieved from this)
- Post ID
- Tag Value

This isn't a lot of information, but there is a critical piece: the Post ID. When I receive that information on the API side, I need to do several things:

1) Does Post with ID #x exist? 
2) Can user edit post with ID #x?
3) Does tag already exist? If so grab it. If not, create it.
3) Update post.

Now, I could send all that data and perform all those functions in a single call -- or I could make separate calls -- the first sucks for scaling and the second sucks for performance. This is a simple example, and my application is highly complex with a lot of different roles/permissions and hierarchies to validate.

Essentially what this boils down to is because I do not manage any state on the API side, each time a request is made I have to reverify a whole series of values which ends up being dozens of queries. I can't rely on the values being correct because a an affluent user could easily modify hidden form inputs or even devise a JSON request and post it effectively compromising the data.

On this OWASP REST security recommendations page, under the section titled "Protect Session State", they suggest caching the blob of information on the API server side and passing a session token instead. To me this goes against the "stateless" principles of REST, but then again, it's more like a cache so can be recalculated if necessary.

TL;DR; How is state managed in complex "API Driven" applications to avoid having dozens of repeated queries on each request and complex sets of input data that the user could modify at any point and compromise the application?

Answer 1

How is state managed in complex "API Driven" applications to avoid having dozens of repeated queries on each request - all state is managed by the data held in the URI. Repeat queries are common with REST

I think the problem you are facing is that you are trying to shoe horn none REST thinking into your design.

The fact of the matter is that EVERY request must contain all the information you need to complete that request - there is no way around this if you want to be 'RESTful'

I can see where your concern lies, as you are having to call the same queries over and over again. But if that is the case, you should design these common queries to be as fast as possible.

Good database/API design will help in the first instance, but I will assume you have done that already.

One thing you may have overlooked is query caching on your database. Your API is RESTful, and you can scale the api as much as you like, but your database server isn't likely to need scaling (unless you have a MASSIVE api, thats very database heavy). So for your common queries, you can actually implement query caching on your database server.

This means, that although you are running a lot of the same queries over and over again, they are just coming out of the database cache.

A simple example from a REST API i am developing is the users credentials. EVERY single request to the API must have the user credentials sent with it. This means that queries to the users table gets executed for every single request BUT I have setup caching on my database, so the users details are returned from there lightening fast.

Your second point relates to data validation. You should of course validate ALL user submitted data - no exceptions.

Answer 2

You shouldn't need to do all of that on the application side, the APIs purpose is to handle complex functionality.

Call for a list of posts, then let the user do their thing, post to an endpoint specifically designed to attach a tag to a post /posts/{id}/tag then look at the response. You should either get a 403 if they didn't have permissions and a 410 if the post doesn't exist.

By all means introduce an ACL, which is returned by the initial /me/get request so you can check permissions against it to prevent the user from first entering the page.

Don't overcomplicate things for yourself, trust the API and trust the responses.