How do their APIs compare?

Now I have a clearer picture. Both projects are desktop applications, not services with formal REST/RPC APIs, but each exposes internal object-oriented "APIs" (public classes/interfaces) that different subsystems use to talk to each other. Here's the comparison:

mzying2001/cefflashbrowser

Its internal APIs are organized around several distinct layers:

• Browser control layer — ChromiumWebBrowserEx, a WPF control extending CefSharp's ChromiumWebBrowser, exposing events (FullscreenModeChanged, FaviconUrlChanged, JsContextCreated, JsContextReleased), dependency properties (FullscreenMode, FaviconUrl, LoadingProgress), and commands (LoadUrlCommand, ShowDevToolsCommand) [CefFlashBrowser.FlashBrowser/ChromiumWebBrowserEx.cs:L12-L127]. It also overrides handler properties (FocusHandler, KeyboardHandler, DisplayHandler, RenderProcessMessageHandler) using a decorator/wrapper pattern.
• CefSharp-for-WinForms-in-WPF bridge layer — CefFlashBrowser.WinformCefSharp4WPF.ChromiumWebBrowser, which surfaces properties like TooltipText, CanExecuteJavascriptInMainFrame, RequestContext, IsBrowserInitialized, IsLoading, CanGoBack [CefFlashBrowser.WinformCefSharp4WPF/ChromiumWebBrowser.cs:L213-L252], plus internal wrapper classes (LoadHandlerWrapper, DialogHandlerWrapper) that adapt CefSharp callback interfaces.
• Native interop layer (C++/CLI) — CefFlashBrowser.Sol, a C++/CLI wrapper (SolFileWrapper, SolArrayWrapper, SolObjectWrapper, SolValueWrapper, SolXml) exposing managed properties/methods (Save(), ReadFile(), CreateEmpty()) over a native SOL (Flash local shared object) parser [CefFlashBrowser.Sol/cli.h:L36-L145].
• Plain data models — simple POCOs like ProxySettings and FakeFlashVersionSetting for app configuration [CefFlashBrowser/Models/ProxySettings.cs:L3-L12, CefFlashBrowser/Models/FakeFlashVersionSetting.cs:L3-L9].
• Utility/logging API — ILogger/FileLogger with Log(LogLevel, message), UrlHelper.IsUrl(...) [CefFlashBrowser.Log/FileLogger.cs:L8-L29].

This is a fairly layered, event/property/command-driven API surface typical of a WPF+CefSharp app, with a distinct native interop boundary via C++/CLI for SOL file manipulation.

nickemanarin/screentogif

From what's been retrieved (the Translator companion tool only), the API surface is much thinner and UI-event-driven: TranslatorWindow methods triggered by WPF events (Window_Loaded, Refresh_Click, ComboBox_KeyDown) that directly perform async I/O (HttpWebRequest/GetResponseAsync) inline rather than through a separate service/handler abstraction [Other/Translator/TranslatorWindow.xaml.cs:L41-L120, L721-L754]. There's a small Dialog/ExceptionDialog helper API for showing modal messages [Other/Translator/Dialog.xaml.cs:L22-L41, Other/Translator/ExceptionDialog.xaml.cs:L49-L71]. No handler-wrapper or interop layer was found in the retrieved data for this tool.

Key differences

• Layering: cefflashbrowser shows a clear multi-layer API design (WPF control → CefSharp bridge → native C++/CLI interop → data models), suited to embedding a browser engine and manipulating binary SOL files. The screentogif Translator code retrieved is much flatter — UI event handlers cal