具有单一入口点的 SOA 的 RESTful
我有一个面向服务的架构，有一个网关可以满足所有客户端请求。我喜欢这个，因为网关很整洁，隐藏了所有“内部”服务，并充当调度程序和自制负载平衡器。
然而，由于我的设计，客户只知道“一个”资源。并且必须发送请求操作及其在 JSON 中定义的参数的消息。
{
"operation" : "Login",
"parameters" :
{
"username" : "John",
"password" : "1234"
}
}
我应该因为我的架构不是 RESTful 而感到悲伤吗？我是否没有像 REST 规定的那样利用 HTTP？请大家批评指正。
I have a service-oriented architecture with a single gateway for all client requests. I like this because the gateway is tidy, hides all "internal" services, and acts as a dispatcher and homemade load balancer.
Because of my design, however, the client only ever knows about "one" resource. And must send up messages that have requested operations and their parameters defined in JSON.
{
"operation" : "Login",
"parameters" :
{
"username" : "John",
"password" : "1234"
}
}
Should I be sad because my architecture is not RESTful? Am I not leveraging HTTP like REST prescribes? Please critique.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不知道“悲伤”这个词是否正确，但支持 REST 的论据之一，特别是在“正确”使用 HTTP 时，它免费为您提供以下内容（摘自 Fielding 的论文） ）：
当如果您使用 SOAP 或其他 RPC 解决方案，而不是 REST，那么理论上您会放弃一些但不是全部这些特性。您可能会放弃客户端可缓存性，并且会按程序进行思考，并且您可能无法充分利用 RESTafarians 所利用的所有安全性和幂等性条件。
RESTful 服务变得非常流行，这并非偶然。但这是否意味着您必须构建 RESTful 服务，或者非 RESTful 服务本质上更糟糕？我不这么认为。我已经为两家不同的公司完成了几个 RESTful SOA，虽然我更喜欢 SOAP（现在看起来很笨重）和像您这样的本土 API（即使很优雅，但不是标准的），但我不喜欢鄙视其他方法并认为它们低劣。
如果您打算使用自己的 API，仅返回 200 和 404，并使用 GET 完成所有操作，那么您的 API 在概念上很简单，也许它会很适合您。但如果您需要多种媒体类型，并且您有持久的存储需求，其中包含经常追加、删除、创建和更新的集合，那么学习现代 RESTful API 设计至少将为您开辟新的思维方式。
最重要的是，不要感到悲伤，也不要觉得自己必须去休息，因为其他人都在这样做。但优点是真实的，REST 不仅仅是炒作。
I don't know if "sad" is the right word, but one of the arguments in favor of REST, especially as implemented in using HTTP "properly" is that it provides to you, for free, the following (taken from Fielding's dissertation):
When you go with SOAP or another RPC solution, instead of REST, you are in theory giving up some but not all of these characteristics. You may be giving up client cacheability and you are thinking procedurally, and you probably can't use all the safety and idempotency conditions that RESTafarians exploit to a tee.
RESTful services have become very popular and not by accident. But does that mean you have to build RESTful services or that non-RESTful services are inherently much worse? I don't think so. I've done a couple RESTful SOAs for two different companies and while I prefer to SOAP (which seems bulky these days) and to home-grown APIs like yours (which, even if elegant, aren't standard), I don't diss other approaches and dismiss them as inferior.
If you are going to go with your own API, and return only 200s and 404s, and do everything with GET, then yes your API is conceptually simple and perhaps it will work fine for you. But if you need a variety of media types, and you have persistent storage requirements containing collections that are often appended to, deleted from, created and updated, then learning modern RESTful API design will at least open up new ways of thinking for you.
Bottom line is don't feel sad nor feel like you have to go to REST because everyone else is doing it. But the advantages are real and REST is not just hype.
没有。基本上，您有一个使用 JSON 而不是 XML 的自制 SOAP 样式 RPC。
您可能会问是否值得使用 JSON 而不是使用 SOAP 堆栈来重新发明它，但如果您使用的是 JavaScript，它可能比 SOAP 更容易使用，而且没有遵守 SOAP 标准/工具集的负担。
除此之外，对我来说似乎很好。
Nope. Basically you have a home brewed SOAP style RPC using JSON instead of XML.
You might ask whether it's worth reinventing that with JSON rather than using a SOAP stack, but if you're talking to JavaScript, it might simply be easier to to use than SOAP, plus there's no burden of conforming with the SOAP standards/tool sets.
Other than that, seems fine to me.