How do their APIs compare?

These two projects are fundamentally different in nature, so "APIs" means something quite different in each — let me lay out both concretely.

stanfordnlp/corenlp: an in-process Java library API

CoreNLP's "API" is primarily a set of Java classes/objects you instantiate and call directly (plus an optional server wrapper, per the README's mention of running "all the tools with just two lines of code"). Based on the retrieved source, it's organized around:

• Data model classes representing linguistic objects, e.g. Mention [src/edu/stanford/nlp/coref/data/Mention.java:L826-L865], CorefCluster [src/edu/stanford/nlp/coref/data/CorefCluster.java:L1-L50], and CorefChain with its nested CorefMention/MentionComparator types [src/edu/stanford/nlp/coref/data/CorefChain.java:L257-L296].
• Static rule/utility classes exposing pure functions rather than REST-style endpoints — e.g. CorefRules.entityTokenDistance(Mention, Mention) and CorefRules.entityCorefDictionary(...) [src/edu/stanford/nlp/coref/CorefRules.java:L920-L959].
• Algorithm classes like FastNeuralCorefAlgorithm, which implements CorefAlgorithm and is constructed with Properties and Dictionaries [src/edu/stanford/nlp/coref/fastneural/FastNeuralCorefAlgorithm.java:L1-L38].
• Static lexical resources exposed as public Set<String> fields for direct consumption, e.g. WordLists.reportVerbEn [src/edu/stanford/nlp/coref/data/WordLists.java:L14-L53].
• Dictionary lookups such as Dictionaries.getDemonyms(String) and Dictionaries.isAdjectivalDemonym(String) [src/edu/stanford/nlp/coref/data/Dictionaries.java:L275-L314].

This is a classic OOP library API: no HTTP contracts in this slice of code, versioning is via Maven Central releases (per README badge), and consumers call Java methods on annotators/pipelines directly.

yunaiv/yudao-cloud: HTTP/RPC microservice APIs

yudao-cloud is a Spring Cloud microservices platform, so its "API" is service-to-service RPC over HTTP, with explicit contracts:

• RPC path conventions are centralized in RpcConstants, defining a shared /rpc-api prefix and per-service prefixes like SYSTEM_PREFIX and INFRA_PREFIX, tied to spring.application.name values (system-server, infra-server) [yudao-framework/yudao-common/src/main/java/cn/iocoder/yudao/framework/common/enums/RpcConstants.java:L10-L41].
• Declarative Feign-style interfaces define the actual endpoints, e.g. ApiErrorLogCommonApi exposes POST /rpc-api/infra/api-error-log/create via @PostMapping, annotated with OpenAPI @Operation, and also offers an @Async fire-and-forget variant createApiErrorLogAsync that wraps the synchronous call and checks the result [yudao-framework/yudao-common/src/main/java/cn/iocoder/yudao/framework/common/biz/infra/logger/ApiErrorLogCommonApi.java:L17-L36].
• Typed request DTOs carry validation annotations for the JSON payload, e.g. ApiErrorLogCreateReqDTO uses @NotNull, Lombok @Data, and Swagger @Schema [yudao-framework/yudao-common/src/main/java/cn/iocoder/yudao/framework/common/biz/infra/logger/dto/ApiErrorLogCreateReqDTO.java:L1-L10].
• Uniform response wrapping via CommonResult<Boolean>, used consistently across RPC methods, with .checkError() for error propagation.

Key contrasts