由于这个旧线程在相关的 Google 搜索中仍然出现率很高，因此我应该加入我对 的高度偏见（作为合著者和用户）的推荐石林。与其他产品不同，Hoodoo 包含一个 API 规范，说明 API 如何调用必须做出以及他们必须如何回应；它增强了您的设计的一致性，呼叫客户会欣赏这一点。如果您可以调用一个 API，那么您就可以调用所有 API。 Hoodoo 实现了许多样板文件，因此您可以专注于有意义的服务代码。
Since this old thread still comes up high on related Google searches, I should chip in my highly biased (as co-author and user) recommendation for Hoodoo. Unlike other offerings, Hoodoo includes an API specification that says how API calls must be made and how they must respond; it enforces a consistency across your design that calling clients will appreciate. If you can call one API, you can call them all. Hoodoo implements a lot of the boilerplate so you can focus on meaningful service code.
We've been using Hoodoo services for over two years very successfully at Loyalty New Zealand, who run the country's largest loyalty programme. Our Hoodoo-based microservice platform handles 100% of our client transactions.
Hoodoo has 100% non-trivial rspec test coverage and 100% rdoc documentation coverage. As you'll see from the above links, there's quite a lot there!
Hoodoo is a Rack application, so works with any Rack compatible web server. Our preferred deployment mechanism though is an indefinitely horizontally scalable arrangement based on an HTTP-over-AMQP bridge and an AMQP cluster of nodes each running the same collection of services, managed inside Docker containers and deployed with Fleet. The system self-load balances across the service nodes via the queue and the decoupling of front end HTTP->AMQP processor versus the AMQP->HTTP input into the Rack stack dramatically reduces the system's attack surface. We wrote the front-end component in Node and for more about this along with Node implementations of other parts of the framework concept, see the Alchemy Framework. Alchemy Node services and Hoodoo Ruby services can coexist on the same grid happily.
For the adventurous, there is also a less known project called grape. It is a rack based application, similar to Sinatra, but is only purposed to write API. I don't think it is mature enough to be used in serious projects yet, but it is still interesting to know.
1) REST, SOAP is a terrible system and its support in Ruby is quite lacking. REST, on the other hand, is basically the ruby default and takes very little effort to use, especially if you are using REST/JSON.
2) Sinatra and Rails are basically your options. It comes down to how complex this application will be. Sinatra can probably handle the task just fine, but Rails does much of the work for you at the expense of bloat. You will already be taking on some of the rails bloat if you use ActiveRecord for the database. When authentication and/or roles come into play, Rails has mature solutions for both. Without any additional information, I'd lean towards Rails as it does much of the work for you and, when written properly, can still be fairly fast.
Actually SOAP is very VERY easy to implement with AWS. At the same time, REST API is also very easy to implement. I have written a couple of different and parallel (JSON, XML and custom format) APIs with rails. Im sure the framework stack performance will not be your bottleneck, so don't bother with worrying about performance just yet. Your first bottleneck will anyhow be database and then perhaps requests per second.
All in all i would suggest going with Rails, it has a lot of work cut out for you.
发布评论
评论（4）
由于这个旧线程在相关的 Google 搜索中仍然出现率很高，因此我应该加入我对 的高度偏见（作为合著者和用户）的推荐石林。与其他产品不同，Hoodoo 包含一个 API 规范，说明 API 如何调用必须做出以及他们必须如何回应；它增强了您的设计的一致性，呼叫客户会欣赏这一点。如果您可以调用一个 API，那么您就可以调用所有 API。 Hoodoo 实现了许多样板文件，因此您可以专注于有意义的服务代码。
我们在 Loyalty New Zealand 中使用 Hoodoo 服务已经两年多了，非常成功，该公司运营着新西兰最大的忠诚度计划。我们基于 Hoodoo 的微服务平台处理 100% 的客户交易。
Hoodoo 拥有 100% 重要的 rspec 测试覆盖率和 100% rdoc 文档覆盖率。正如您从上面的链接中看到的，那里有很多东西！
Hoodoo 是一个 Rack 应用程序，因此可以与任何 Rack 兼容的 Web 服务器一起使用。不过，我们首选的部署机制是基于 HTTP-over-AMQP 桥接器的无限水平可扩展安排以及一个 AMQP 节点集群，每个节点都运行相同的服务集合，在 Docker 容器内进行管理并使用 Fleet 进行部署。系统通过队列在服务节点之间进行自负载平衡，前端 HTTP->AMQP 处理器与 Rack 堆栈中的 AMQP->HTTP 输入的解耦极大地减少了系统的攻击面。我们在 Node 中编写了前端组件，有关此内容以及框架概念其他部分的 Node 实现的更多信息，请参阅 炼金术框架。 Alchemy Node 服务和 Hoodoo Ruby 服务可以在同一个网格上愉快地共存。
Since this old thread still comes up high on related Google searches, I should chip in my highly biased (as co-author and user) recommendation for Hoodoo. Unlike other offerings, Hoodoo includes an API specification that says how API calls must be made and how they must respond; it enforces a consistency across your design that calling clients will appreciate. If you can call one API, you can call them all. Hoodoo implements a lot of the boilerplate so you can focus on meaningful service code.
We've been using Hoodoo services for over two years very successfully at Loyalty New Zealand, who run the country's largest loyalty programme. Our Hoodoo-based microservice platform handles 100% of our client transactions.
Hoodoo has 100% non-trivial rspec test coverage and 100% rdoc documentation coverage. As you'll see from the above links, there's quite a lot there!
Hoodoo is a Rack application, so works with any Rack compatible web server. Our preferred deployment mechanism though is an indefinitely horizontally scalable arrangement based on an HTTP-over-AMQP bridge and an AMQP cluster of nodes each running the same collection of services, managed inside Docker containers and deployed with Fleet. The system self-load balances across the service nodes via the queue and the decoupling of front end HTTP->AMQP processor versus the AMQP->HTTP input into the Rack stack dramatically reduces the system's attack surface. We wrote the front-end component in Node and for more about this along with Node implementations of other parts of the framework concept, see the Alchemy Framework. Alchemy Node services and Hoodoo Ruby services can coexist on the same grid happily.
对于喜欢冒险的人来说，还有一个鲜为人知的项目，名为 grape。它是一个基于机架的应用程序，类似于 Sinatra，但仅用于编写 API。我认为它还不够成熟，无法用于严肃的项目，但了解它仍然很有趣。
For the adventurous, there is also a less known project called grape. It is a rack based application, similar to Sinatra, but is only purposed to write API. I don't think it is mature enough to be used in serious projects yet, but it is still interesting to know.
1）REST，SOAP是一个糟糕的系统，并且Ruby对它的支持非常缺乏。另一方面，REST 基本上是 ruby 默认设置，使用起来非常轻松，尤其是在使用 REST/JSON 时。
2) Sinatra 和 Rails 基本上是您的选择。这取决于这个应用程序的复杂程度。 Sinatra 可能可以很好地处理该任务，但 Rails 会为您完成大部分工作，但代价是臃肿。如果您使用 ActiveRecord 作为数据库，您将已经承受了一些 Rails 的膨胀。当身份验证和/或角色发挥作用时，Rails 对此都有成熟的解决方案。如果没有任何其他信息，我会倾向于 Rails，因为它为您完成了大部分工作，并且如果编写得当，仍然可以相当快。
1) REST, SOAP is a terrible system and its support in Ruby is quite lacking. REST, on the other hand, is basically the ruby default and takes very little effort to use, especially if you are using REST/JSON.
2) Sinatra and Rails are basically your options. It comes down to how complex this application will be. Sinatra can probably handle the task just fine, but Rails does much of the work for you at the expense of bloat. You will already be taking on some of the rails bloat if you use ActiveRecord for the database. When authentication and/or roles come into play, Rails has mature solutions for both. Without any additional information, I'd lean towards Rails as it does much of the work for you and, when written properly, can still be fairly fast.
实际上，使用 AWS 实现 SOAP 非常非常容易。
同时，REST API也非常容易实现。
我用 Rails 编写了几个不同的并行 API（JSON、XML 和自定义格式）。我确信框架堆栈性能不会成为您的瓶颈，因此暂时不必担心性能。无论如何，您的第一个瓶颈将是数据库，然后可能是每秒的请求。
总而言之，我建议使用 Rails，它需要你做很多工作。
Actually SOAP is very VERY easy to implement with AWS.
At the same time, REST API is also very easy to implement.
I have written a couple of different and parallel (JSON, XML and custom format) APIs with rails. Im sure the framework stack performance will not be your bottleneck, so don't bother with worrying about performance just yet. Your first bottleneck will anyhow be database and then perhaps requests per second.
All in all i would suggest going with Rails, it has a lot of work cut out for you.