在阅读official guide关于如何构建项目并浏览各种（1，2，3等等）示例和项目后，我不能帮助我想知道我的构建我的REST-API服务器应用程序的方法是否正确 。
/auth/sign-in 接受username和password并发出JWT（JSON网络令牌）。
/auth/sign-out 将JWT添加到黑名单以使auth会话无效。
/resources 检索所有资源的列表。
/resources（需要有效的JWT身份验证）接受JSON正文，创建新资源并向每个人发送有关新资源的电子邮件和通知。
目前我没有创建任何库。一切都在主包中，包含路线等的总体服务器设置都在main.go完成。我没有去找Rails或Django中的MVC模式，以避免过于复杂的事情。另外我的印象是它并没有真正符合上面已经提到的guide所述的命令和库的推荐结构。
auth.go # generates, validates JWT, etc
auth-handler.go # Handles sign-in/out requests; includes middleware for required authentication
mailer.go # Provides methods to send out transactional email, loads correct template etc.
main.go # set up routes, runs server; inits mailer and notification instance for the request context
models.go # struct definition for User, Resource
notifications.go # Provides methods to publish push notifications
resource-handler.go # Handles request for resources, uses mailer and notifications instances for the POST request
路线应该分开吗？中间件怎么样？您如何处理第三方代码的接口 - 在概述的示例应用程序中与Mandrill和mailer.go交谈亚马逊AWS SNS时想象notifications.go？
答案 0 :(得分：1)
我可以根据自己的经验分享一下。
在应用程序代码中：
与库代码相反，分离到包和子包不太重要 - 只要您的代码没有太多复杂性。我主要将应用程序设计为集成自包含库，因此应用程序代码本身通常很小。一般情况下，如果您真的不需要，请尽量避免包分离。但是，不要只是在一个软件包中砸大量代码 - 这也很糟糕。
但是没有像“util”这样的通用软件包，他们很快就会开始积累行李并且吮吸。我有一个单独的repo for generic utils可以跨项目重用，在它下面每个实用程序API都是一个子包。例如github.com/me/myutils/countrycodes，github.com/me/myutils/set，github.com/me/myutils/whatevs。
无论包结构如何，最重要的是将内部API与处理程序代码分开。处理程序代码应该是一个处理输入的非常薄的层，并调用内部的自包含API，可以在没有处理程序的情况下进行测试，也可以绑定到其他处理程序。看起来你正在这样做。然后你可以将内部API分离到另一个包中，这并不重要。
当您决定将代码的哪些部分分成库时，请考虑代码重用。如果此代码仅由您的应用使用，那就没有意义了。
我喜欢在第二个包中定义的接口中包装与第三方API的集成。例如，如果您有类似于使用AWS SES发送电子邮件的内容，我将创建一个名为github.com/my_org/mailer的pakcage，其中包含一个抽象接口，并在其下创建一个实现SES集成的github.com/my_org/mailer/ses包。应用程序代码导入mailer包及其接口，并且仅在main中以某种方式注入SES的使用并将各种内容集成在一起。
重新使用中间件 - 我通常将它与API本身放在同一个包中。