Compatibility-Aware Web API Recommendation for Mashup Creation via Textual Description Mining
Bibliographic record
Abstract
With the ever-increasing prosperity of web Application Programming Interface (API) sharing platforms, it is becoming an economic and efficient way for software developers to design their interested mashups through web API re-use. Generally, a software developer can browse, evaluate, and select his or her preferred web APIs from the API's sharing platforms to create various mashups with rich functionality. The big volume of candidate APIs places a heavy burden on software developers’ API selection decisions. This, in turn, calls for the support of intelligent API recommender systems. However, existing API recommender systems often face two challenges. First, they focus more on the functional accuracy of APIs while neglecting the APIs’ actual compatibility. This then creates incompatible mashups. Second, they often require software developers to input a set of keywords that can accurately describe the expected functions of the mashup to be developed. This second challenge tests partial developers who have little background knowledge in the fields. To tackle the above-mentioned challenges, in this article we propose a compatibility-aware and text description-driven web API recommendation approach (named WAR text ). WAR text guarantees the compatibility among the recommended APIs by utilizing the APIs’ composition records produced by historical mashup creations. Besides, WAR text entitles a software developer to type a simple text document that describes the expected mashup functions as input. Then through textual description mining, WAR text can precisely capture the developers’ functional requirements and then return a set of APIs with the highest compatibility. Finally, through a real-world mashup dataset ProgrammableWeb, we validate the feasibility of our novel approach.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.001 | 0.010 |
| Meta-epidemiology (narrow) | 0.002 | 0.001 |
| Meta-epidemiology (broad) | 0.001 | 0.002 |
| Bibliometrics | 0.008 | 0.005 |
| Science and technology studies | 0.001 | 0.001 |
| Scholarly communication | 0.002 | 0.004 |
| Open science | 0.002 | 0.001 |
| Research integrity | 0.001 | 0.001 |
| Insufficient payload (model declined to judge) | 0.002 | 0.002 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".