依赖于上下文的REST API策略

Question

What strategies would you suggest for making a RESTful API "context dependent"?

Let me elaborate.

On a project that I'm working on we are exposing a resource Team . Users can create their own teams, which results in a POST /teams request to the API. The request is validated using set of rules meant for user created teams.

We also have an administration interface which is used by certain users to create the same type of Team resource, however this is governed by a slightly different set of validation rules.

Administrators may use either our public or administration interface, and so the validation has to happen based on their context, not the user's capabilities.

To rephrase the question above for this specific situation: How do we separate between these two contexts in a RESTful way? Do we create two different resources even if the "result" is of the same type, and if so what naming conventions would you suggest?

Answer 1

Nothing in REST guarantees that a resource will behave identically for different clients. Furthermore, since the authorization information is attached to each request, it is natural for resource to analyze it and apply client-specific logic to request.

But! If some operations on your resource introduce complex resource invariants with dependent lifetimes of resource's parts, you'd better refactor it early into smaller resources. For example, if an Administrator should add a member to the team and then a RegularUser should fill the details of the member in the team ... You've probably noticed, that there's two resources - team and member .

HINT: When decomposing complex resource which participates in different operations, you can get new ideas by imagining future scaling problems caused by different clients. What if you'll be overhelmed by one client of the resource, how would you achieve stable reply for another client? It's easier to scale different resources than different part of one resource, so look at your operations and think about scaling.

Answer 2

I believe what you should do is create a 'user-level' token or just a user for each admin that they should use when they want the public interface.

There is only one interface, namely /teams in terms of REST API, and your token can decide the validation rules.

Or if each admin is responsible from a team I'd design /admins/x/teams endpoint to validate differently and only accept x's authentication. sub-resources are still RESTful.