How do their APIs compare?

These two projects are architecturally very different — one isn't even really an "API" in the network sense — so a direct comparison is mostly about contrasting paradigms rather than finding overlap.

naman14/timber: local, in-process data & third-party REST APIs

Timber is an Android app, so its "APIs" are of two kinds:

1. Internal data-access APIs — static loader classes that wrap ContentResolver queries against Android's MediaStore to fetch songs/albums/artists. These aren't network endpoints; they're synchronous Java methods returning in-memory model objects.

   • SongLoader.getAllSongs(), getSongForID(), searchSongs(), makeSongCursor() build Cursor queries against MediaStore.Audio.Media [app/src/main/java/com/naman14/timber/dataloaders/SongLoader.java:L117-L151].
   • AlbumLoader mirrors this pattern for MediaStore.Audio.Albums — getAllAlbums(), getAlbum(), getAlbums() [app/src/main/java/com/naman14/timber/dataloaders/AlbumLoader.java:L27-L78].
   • These follow a consistent convention: a makeXCursor() builder + a getXForCursor() converter, with sort order pulled from PreferencesUtility.

2. External REST API — a Last.fm client built on Retrofit, used to fetch album/artist metadata and scrobble tracks.

   • LastFmRestService defines two @GET endpoints (album.getinfo, artist.getinfo) with hardcoded API key parameters and Retrofit Callback-based async responses [app/src/main/java/com/naman14/timber/lastfmapi/LastFmRestService.java:L25-L39].
   • LastFmClient is a singleton wrapping the Retrofit service instances (mRestService, mUserRestService) plus session state for authenticated scrobbling [app/src/main/java/com/naman14/timber/lastfmapi/LastFmClient.java:L47-L86].

This is old-style Java Retrofit (retrofit.Callback, not RxJava/coroutines), and per the RepoPilot verdict, the project is stale and unlicensed (last commit 3 years ago), so treat these API keys/patterns as unmaintained rather than best-practice reference.

yunaiv/yudao-cloud: internal microservice RPC APIs

yudao-cloud is a Spring Cloud microservices backend, and its "APIs" are formal inter-service RPC contracts defined as Java interfaces annotated with Spring MVC/OpenAPI annotations, shared via a common module (yudao-framework/yudao-common):

• PermissionCommonApi exposes permission/role/data-scope checks (hasAnyPermissions, hasAnyRoles, getDeptDataPermission) as @GetMapping endpoints under a shared RpcConstants.SYSTEM_PREFIX path convention, returning a standardized CommonResult<T> wrapper [yudao-framework/yudao-common/src/main/java/cn/iocoder/yudao/framework/common/biz/system/permission/PermissionCommonApi.java:L16-L43].
• Request/response payloads are explicit DTOs with Bean Validation (@NotNull, @NotEmpty) and OpenAPI @Schema docs for every field, e.g. OperateLogCreateReqDTO [yudao-framework/yudao-common/src/main/java/cn/iocoder/yudao/framework/common/biz/system/logger/dto/OperateLogCreateReqDTO.java:L11-L52] and OAuth2AccessTokenCheckRespDTO [yudao-framework/yudao-common/src/main/java/cn/iocoder/yudao/framework/common/biz/system/oauth2/dto/OAuth2AccessTokenCheckRespDTO.java:L13-L34].
• This reflects a much more formal, self-documenting, multi-tenant-aware API design (tenant IDs, user types, trace IDs baked into DTOs), consistent with an enterprise multi-module backend rather than a single mobile client.

Key contrasts