使用 URL 字符串进行 API 调用的更好方法

Question

我们与同事进行了讨论，但没有达成共识。我将感谢良好的论据和真实的使用体验。问题是：声明 URL 路径的更好方法是什么，例如在使用 Retrofit 的 Android 应用程序中？对 URL 中的所有路径项使用单独文件中的静态字符串常量。    @GET("$VIDEOS/$PUBLIC/{$SLUG}")    fun getVideos(@Path(SLUG) slug: String, @Query(LIMIT) limit: Int): List<Video>使用常规字符串。    @GET("videos/public/{slug}")    fun getVideos(@Path("slug") slug: String, @Query("limit") limit: Int): List<Video>

Answer 1

如果初始字符串在代码库的不同区域中使用，例如，如果您有两个具有相同$VIDEOS路径的不同 URL，则常量可能非常强大，因为您可以一次编辑所有这些。然而，仅仅因为常量“可能”用在不同的地方就创建它们，维护起来可能会是一场噩梦。例如，如上所述，两个 API 使用该$VIDEOS路径，但只有一个发生更改。

然而，另一方面，在这里使用可能有一个好处，那就是使用slug您的示例中的 , 但已编辑。

private const val SLUG = "thing"

@GET("videos/public/{$SLUG}")

fun getVideos(@Path($SLUG) slug: String, @Query("limit") limit: Int): List<Video>

因为这是在同一个 API 调用中使用的，但在两个区域内。要点是你可以将事物变成常量，但前提是它有意义。尽量不要抽象掉整个 API，因为一旦这样做，更改和维护就会变得更加困难。

当有疑问时，我也会求助于库本身的示例。Retrofit 文档此处的示例没有任何常量。

Answer 2

使用第二种方法，代码变得更具可读性 - 这是一个非常重要的优势。

使用第一种方法的优点是，如果路径的某些部分发生变化，则只能在一个地方进行更改。但这是一个值得怀疑的优势，因为路径很少改变，而且第二个选项的改变也不需要太多时间。

第二种方法的缺点：

• 创建了需要跟踪的额外依赖项，并且您可能会错误地更改不需要的内容，

• 您必须检查每个常量中的内容以确保路径正确。

因此，答案是选项 2（常规字符串）更好。