How do their APIs compare?

These two projects are fundamentally different in kind, so "API" means something quite different in each — there isn't really a meaningful direct comparison, but here's how each is structured:

pqpo/smartcropper — a client-side library API (Java/Android + native)

smartcropper doesn't expose network/HTTP APIs — it's an Android library whose "API" is a small set of Java classes/methods meant to be called directly in-process by an Android app, backed by native (JNI/OpenCV) code for the actual image processing. Per the README:

• SmartCropper.buildImageDetector(this) — initializes the ML-based edge detector (HED network via TensorFlow Lite), typically called once in Application.onCreate.
• CropImageView — a custom view (subclass of ImageView) used declarative in XML layouts, with attributes like civMaskAlpha, civShowGuideLine, civLineColor, etc. for configuring the crop overlay UI.
• ivCrop.setImageToCrop(selectedBitmap) — loads a bitmap and triggers native-layer smart border detection.
• ivCrop.crop() — returns a Bitmap, performing the perspective-transform crop/correction, again mostly running in native code.

This is documented in the README excerpt under "使用" (usage) in the repository data. Both crop() and setImageToCrop() are noted as running primarily in native code with runtime proportional to image size, so the README recommends running them off the main thread for large images.

There's no REST/RPC layer here — it's a UI widget + native image-processing library consumed via Gradle/JitPack dependency.

yunaiv/yudao-cloud — a microservices REST/RPC API surface

yudao-cloud is a Spring Cloud-based backend, and its "APIs" are HTTP REST endpoints and internal RPC contracts between microservices, e.g.:

• ApiErrorLogCommonApi — an RPC-style interface with a @PostMapping endpoint for creating API error logs, plus an @Async convenience method createApiErrorLogAsync that wraps the synchronous call and checks the result via .checkError() [yudao-framework/yudao-common/src/main/java/cn/iocoder/yudao/framework/common/biz/infra/logger/ApiErrorLogCommonApi.java:L17-L36].
• ApiAccessLogCommonApi — the analogous interface for access logs, same pattern: createApiAccessLog (sync, validated via @Valid @RequestBody) and createApiAccessLogAsync [yudao-framework/yudao-common/src/main/java/cn/iocoder/yudao/framework/common/biz/infra/logger/ApiAccessLogCommonApi.java:L17-L36].
• Request DTOs like ApiErrorLogCreateReqDTO use Swagger annotations (@Schema) and Bean Validation (@NotNull) for documenting and validating the RPC payloads [yudao-framework/yudao-common/src/main/java/cn/iocoder/yudao/framework/common/biz/infra/logger/dto/ApiErrorLogCreateReqDTO.java:L1-L10].

This reflects a typical microservice pattern: common API interfaces shared across modules, backed by CommonResult wrappers, validated DTOs, and OpenAPI/Swagger documentation — a world apart from smartcropper's local Bitmap-in/Bitmap-out method calls.

Bottom line

• smartcropper: a tiny, synchronous, in-process Java API over native image-processing code — no network semantics, no request validation framework, just view configuration and bitmap methods.
• yudao-cloud: a distributed system's API surface — versioned REST/RPC contracts, DTO validation, async wrappers, and Swagger docs across many domains (logging shown here is just one example; the broader system spans many more modules).

I don't have visibility into a broader endpoint inventory for yudao-cloud from what's retrieved so far — I only have the logging-related API interfaces shown here. If you want, I can search for more API surfaces (e.g., system/member/pay modules) to broaden the comparison.

FOLLOW_UPS:

• What other yudao-cloud API modules exist besides logging?
• How does smartcropper's native JNI layer work internally?
• What validation patterns does yudao-cloud use for DT