1

So in REST I have a product resource...

http://api/product

Question is what if I've got some domain logic? In an Object Oriented world, I might have

public class product
{
    int id;

    public product(){}

    public int Calc(int first, int second)
    {
        return first + second;
    }
}

How do I represent this business logic? I assume I can do...

    public int GetCalc(int id, int first, int second)
    {
        localProduct = products[id];
        return localProduct(first + second);
    }

Hence the URL of the service would become 

http://api/product/Calc?id=1&first=1&second=2

OR (alternatively)

http://api/product/1/Calc?first=1&second=2

This returns the correct result.... I'm just wondering if this is how I should represent business business logic? Or should I be doing this a different way or trying to avoid it altogether? I'd welcome any ideas on how to improve this...

4

2 回答 2

1

这可能很大程度上取决于您构建的系统。花点时间思考这将如何随着时间的推移而演变，因为这很难重构。您前进的总体方向看起来不错。

此 API 调用

http://api/product/Calc?id=1&first=1&second=2

在我看来是正确的。所以你有一个Product控制器，它有一个方法Calc并接受参数id，first和second。

我不太清楚如何处理这个 API

http://api/product/1/Calc?first=1&second=2

对我来说，它Product有很多ids，每个都id可以调用Calc带有参数的方法，first并且second。也许在您的业务领域中它是有道理的，我只是看不到它。

于 2013-05-09T19:42:21.423 回答
0

好吧，理论上 REST 不应该处理逻辑，而应该只处理状态（REST = 代表性状态转移）。

当然，我明白你的意思，如果我需要计算值怎么办？

在我看来，你应该尽量避免它。

如果这不可能，我只会公开一个代表对象状态的 ViewModel 并保持模型的逻辑对外界隐藏。这可以确保您进行了显式转换，并且还明确声明您正在发送对象的状态而不是对象本身。

但这基本上取决于情况，并没有真正的硬性规定。我会说现在最有意义的事情。如果您发现它变得笨拙，请将其重构为更好的解决方案。

于 2013-05-09T19:41:14.540 回答