CRUD RESTful API中的业务逻辑

Question

Summary

I want to prevent users who have been flagged as spammers from sending messages on my application. Should the Messaging API validate that the sending User is not a spammer (thereby returning a 400)? Or is it the responsibility of the caller?

The architecture:

Details

There are a couple apps and a website consuming CRUD RESTful API's of which there are two, one for Users and one for Messaging.

The debate is whether the caller of the Messaging API is responsible for validating the spamming status of the User.

Pros of Messaging API doing the validation:

• Business logic is uniformly enforced. Future consumers won't forget to enforce it.
• Maintenance is also easier, one place not three.

Cons of Messaging API doing the validation:

• Downside is that validation will require a call from the Messaging API to the User API which is smelly.
• This is also slow and added overhead for every POST to the Messaging API. The caller often already has the user profile available.
• Also dirties what thus far has been a very simple and clean implementation of the API's.

Thoughts?

Answer 1

You could consider a third option. You wrote:

The caller often already has the user profile available.

You could demand each Message API request to include the user profile. Then, the Message API can detect spammers without calling the User API.

Pros:

• Business logic is uniformly enforced.
• Maintenance is easier: one place, not three.
• Message API and User API remain disconnected.
• Message API performance is not significantly affected.

Cons:

• Clients must always send the user profile in each request to the Message API (more complex to implement, message API requests are polluted by data not directly related to the purpose of the request)
• Clients that do not have the user profile yet, must perform an extra request to the User API.

I'm not saying that this option is the best, it is just another candidate to consider. Which option is the best depends on the weights of each pro and con argument. You and your team members should judge which aspects are most important in your organization and your specific situation.

Answer 2

Business logic always clutters up services. Some people get around this by separating business services from infrastructure/data services. This unfortunately just seems to make things more complicated down the road when a single infrastructure data service causes many business services to change.

Don't distribute your business logic. It's not worth it to keep a service "clean". This "clean" implementation is a fiction. You already have lots of coupling to other services, you just aren't thinking of them that way. I guarantee you are relying on a SMTP or MQ service for your messaging. They just aren't services you have written.

I would encapsulate your access to your user service like you would any other data access (like a database). Wrap it in a DAO or a Repository pattern. At that point, you can evaluate whether you are hitting a performance issue, and if so, implement a caching layer for your users to resolve it.