API包装器架构最佳实践

Question

我正在编写一个围绕REST the服务的Perl包装器模块，我希望能得到一些关于如何最好地构建该模块的建议。

我一直在研究几个不同的Perl模块以获取灵感。

Flickr::Simple2基本上是一个大文件，其中包含Flickr API中不同方法的方法，例如getPhotos()等。

Flickr::API是另一个模块(LWP)的子类，用于发出HTTP请求。因此，基本上它只允许您使用LWP通过模块进行调用，这些调用转到正确的API方法/URL，而不需要定义任何包装方法本身。这一点解释得很糟糕--但基本上它有一个接受参数( API方法名)的方法，并构造正确的API调用，例如request()/response()。

另一种设计将与第一种设计类似，但不是那么单一，为API的单独“区域”提供单独的类。

我喜欢遵循现代/最佳实践的Perl方法，所以我使用Dist::Zilla和Moose来构建面向对象的模块，但我希望能就如何实际设计/架构我的包装器提供一些意见。

指南/教程或其他设计良好的模块的指针将不胜感激。

干杯

Answer 1

这在一定程度上取决于您试图包装的API的广度/深度。

如果它只有几个简单的API调用，那么第一种方法就可以了。

如果它有非常复杂的API，并且具有您希望向用户公开的“简单”模式，一种模式是让主模块并子类它作为Main:: module ::Simple，它将包装主要的底层模块。

正如您所提到的，将一个非常广泛的API拆分成多个区域，并由并行类(可能是继承自或使用基类)负责包装每个区域，这可能会带来好处。只要确保把所有常见的东西都去掉，就可以避免任何代码/设计的重复。

Answer 2

Joshua Bloch对"How to Design a Good API and Why it Matters“有很好的建议(视频，2007)。

slides (PDF)。