标题翻译
Should I make my REST client API library Async (Java 8)
问题
我正在为我们的REST服务器创建客户端库。对于C#库，我使用HttpClient.PostAsync()，它运行良好，它返回一个对象，调用方可以等待（使其同步），他们可以完成其他一些操作然后等待，或者他们可以使用C#的await机制。非常棒的解决方案。
对于Java，我必须为Java 8编写库，因为这是最广泛使用的版本。使用Java 8，我们覆盖了98%的程序员。 （如果需求足够的话，我也会做一个Java 11版本，这样我们就有了原生的异步调用。）
所以我的问题是，有多种方法可以获得异步行为，可以使用DeferredResult或一些第三方类。但是，是否有优势来围绕这一点构建我的API并强制使用它呢？因为如果我创建一个同步API，调用者仍然可以在他们自己的DeferredResult代码中调用它。这是相同的最终结果。
所以在我看来，提供一个简单直接的API的方法是提供一个同步的API。那些想要异步的人可以使用他们喜欢的任何机制将其包装成异步。这里的一个重要优势是我不会强制使用他们不使用的机制或第三方库。
这种方法有什么不利之处吗？
更新： 这是更详细的信息。
如果我只有一个同步API，那么调用者可以用许多不同的方式来包装我的同步API。在纯Java 8中，最简单的方式是：
// API是：public Metrics postMetrics(Template template)
CompletableFuture<Metrics> completableFuture = CompletableFuture.supplyAsync(() -> { return client.postMetrics(template); });
如果我创建了一个异步API，那么我要选择这些方法之一（我会使用CompletableFuture），所以API变成了：
// API是：public CompletableFuture<Metrics> postMetrics(Template template)
CompletableFuture<Metrics> completableFuture = client.postMetricsAsync(template);
诚然，使用那个异步API会更容易一些。但几乎没有什么区别。而且缺点是我现在已经强制在他们身上使用了异步方法。我是否忽略了提供异步API的某些更大优势？
英文翻译
I am creating client libraries for our REST server. For the C# library I use HttpClient.PostAsync() which works great, it returns an object that the caller can just wait on (making it synchronous), they can complete some other actions and then wait, or they can use the C# await mechanism. Great solution.
For Java I have to write the library for Java 8, because that's the version in the largest use. With Java 8 we cover 98% of the programmers out there. (If we get enough demand, I'll do a Java 11 one also and then we have native async calls.)
So here's my question, There are ways to get async behavior, either using DeferredResult or some 3rd party classes. But is there any advantage to my building my API around this and forcing it? Because if I create a synchronous API, the caller can still call it in their own DeferredResult code. Which is the same end result.
So it seems to me the way to provide a simple straightforward API is to deliver a synchronous one. And those that want async wrap it up in whatever mechanism they prefer to make it async. An important advantage here is I don't force a mechanism or 3rd party library they don't use on them.
Is there any downside to this approach?
Update: Here it is in more detail.
If all I have is a synchronous API, then the caller can wrap my synchronous API in many different ways. The easiest using vanilla Java 8 is:
// API is: public Metrics postMetrics(Template template)
CompletableFuture<Metrics> completableFuture = CompletableFuture.supplyAsync(() -> { return client.postMetrics(template); });
If instead I create an async API, then I am choosing which of these approaches (I would use CompletableFuture) and so the API becomes:
// API is: public CompletableFuture<Metrics> postMetrics(Template template)
CompletableFuture<Metrics> completableFuture = client.postMetricsAsync(template);
Granted, it's a bit easier with that async API. But very little difference. And the downside is I've now forced the async approach on them. Am I missing some larger advantage of providing an async API?
答案1
得分: 0
这不是相同的最终结果。
同步 I/O 在被阻塞的线程上消耗大量内存。这是同步方法的主要缺点。将同步 I/O 作为主要方法，你的异步 I/O 仍然需要同步 I/O，因此将消耗大量资源。
合理的方法是将异步接口作为主要方法，并使用同步方法进行补充。然后用户可以选择是否愿意为阻塞的线程分配内存，或者使用最少的资源进行多个 I/O 操作。
英文翻译
It is not the same end result.
Synchronous I/O consumes a lot of memory for blocked threads. This is the main disadvantage of synchronous approach. Making synchronous I/O as primary, your asynchronous I/O still will require synchronous I/O and so will consume a lot of resources.
Rational approach is to make asynchronous interface primary and augment it with synchronous methods. The user then can choose if he can afford to spend memory for blocked threads or to employ multiple I/O operations using minimal resources.
答案2
得分: 0
也许你应该从这些角度来考虑，如果明天出现了另一个竞争性的库，它可以提供开箱即用的异步行为和同步行为呢？
如果我是开发者，也许我会选择那个可以为我提供开箱即用的异步行为，并且还能给我配置选项的库。
我所说的只有在你从开发者采纳和内置的轻松进行异步API调用的角度来考虑时才有意义。
希望这可以帮助你。
英文翻译
Perhaps you should think in these terms, what if tomorrow there is another competing library that provides async behavior out of the box and sync as well ?
If I was a developer, I would perhaps choose the one that allows me the async behavior out of the box and also gives me the options to configure it.
What I have said only makes sense if you are thinking in terms of easy developer adoption and inbuilt ease of making async API calls.
I hope this helps.
专注分享java语言的经验与见解，让所有开发者获益！
评论