通过我自己的RESTful API路由API调用是否被视为可接受的策略？

如何解决通过我自己的RESTful API路由API调用是否被视为可接受的策略？

这个问题可能被认为是有道理的，但我似乎似乎找不到直接的答案。所以我丢失了一些东西，或者问了错误的问题。因此，我是一名本科生，并且是整个Spring应用程序开发的新手，我目前正在创建一个以React为前端的应用程序，并使用Spring构建RESTful API，以便为后端提供必要的操作来支持它。在其他服务中，我正在构建的后端API用作中间人来转发对Google Geocoding API和其他第三方API的调用。 **自从我开始这样做以来，我最大的问题是，这是有效的策略吗？ **（至少，这是行业专业人士可接受的东西）

我的研究

此方法的最大优点是，它使我可以从客户端有效隐藏我的API密钥，从而无法进行任何攻击。
与此同时，整个过程增加了（我认为）不必要的复杂性和整体响应的延迟，从而可能会阻碍用户体验。
我不太确定是否需要为自己的API公开的服务添加async功能，以便于多个用户使用。（这最后一部分可能是完全错误的，但我无法理解同时查询同一终结点时如何处理多个用户。）
我已使用Apache JMeter在并发POST调用中测试应用程序的性能，它似乎能够在170ms左右的时间内处理它们。（我将在下面发布结果的屏幕截图。）

代码

我将尝试包含代码来演示负责Geocoding API调用的控制器。

@RestController
@RequestMapping("/api")
@Slf4j
@RequiredArgsConstructor
@Component
public class GeocodingController {
    private final OkHttpClient httpClient = new OkHttpClient();

    @PostMapping(value = "/reversegeocoding")
    public String getReverseGeocode(@RequestBody LatLng latlng) throws IOException,ExecutionException,InterruptedException {
        String encodedLatLng = latlng.toString();
        Request request  = new Request.Builder()
                .url("https://maps.googleapis.com/maps/api/geocode/json?" +
                        "language=en&result_type=street_address&latlng=" + encodedLatLng +
                        "&key=MY_API_KEY")
                .build();

        CallbackFuture future = new CallbackFuture();
        httpClient.newCall(request).enqueue(future);
        Response response = future.get();
        return response.body().string();

    }
}

getReverseGeocode()方法将以下对象作为参数：

@Data
@AllArgsConstructor
@NoArgsConstructor
public class LatLng {

    double lat;
    double lng;

    public String toString() {
        return lat + "," + lng;
    }
}

因此，一旦请求到达，Request Body就被映射到上述对象。
最后，CallbackFuture只是基于this答案的适配器类。

public class CallbackFuture extends CompletableFuture<Response> implements Callback {

    @Override
    public void onFailure(Call call,IOException e) {
        super.completeExceptionally(e);
    }

    @Override
    public void onResponse(Call call,Response response) {
        super.complete(response);
    }
}

JMeter结果

解决方法

是的，这一直都在做。并非所有外部API都已设置为允许您直接向用户授予访问权限。您可能还对日志记录和/或访问控制有要求。这确实意味着您需要将资源专用于这些调用，但是除非您预期负载过大，否则就不值得提前进行过多的优化。有时，您可以将代理职责转移到像nginix这样的东西上，而不是像应用程序后端那样高效。

根据我的经验，值得将这些代理保存在自己的单独程序包中，并尽可能与您的其他代码隔离。然后，如果您需要独立于主应用程序扩展它们，则可以轻松地将它们分解。

是的，这是完全有效的策略。使用这种方法有很多好处，尽管感觉上好像增加了不必要的复杂性，但好处通常超过了成本。

首先，您要避免“泄漏抽象”，客户端不必关心如何实现特定功能，他们只关心它的功能！这也意味着您将来甚至可以在客户不知情的情况下更改实现。

第二，您正在将API与其他API分离。如果包装的API发生更改，则您可以自己处理此问题，而无需客户端更改代码（有时可能无法完成，但是对此提供了很好的保护）。

此外，它还为您提供了方便的点，以围绕这些API实现自己的功能（例如速率限制，访问控制和日志记录）。

@Async问题不是包装第三方API所特有的，这是所有具有阻塞IO的端点的问题。

这很常见。最近，这对添加跨源标头的第三方api进行了处理，因此客户端可以执行跨源请求。另外，在某些情况下，原始JSON的格式也有误，因此可以彻底处理该情况。

首先使用Spring引导非常容易，因为您可以使用android.os.Build装饰控制器

通过我自己的RESTful API路由API调用是否被视为可接受的策略？

如何解决通过我自己的RESTful API路由API调用是否被视为可接受的策略？

我的研究

代码

JMeter结果

解决方法

相关推荐