lysine-dev/retrofit

A type-safe HTTP client for Android and the JVM

19
Hotness score
36
Reliability score
43,918
Stars
almost 16 years
Age
0
Published reviews
0
Questions

Scores

Hotness and reliability

The two headline scores, measured daily, with 30, 90, and 180 day views.

Hotness score

Jul 19, 2026

Current19

Previous7

Weekly average

100500
Full metrics details

Derived only from GitHub GraphQL starredAt events after daily star totals are reconciled.

180 observed daily rows. Missing days are not fabricated.

Hotness formula

40% Hot today + 40% Hot this week + 20% Breakout.

  • 40% Hot today: 30
  • 40% Hot this week: 44
  • 20% Breakout: 84
  • Stars gained: 1d: 3
  • Stars gained: 7d: 8
  • Stars gained: 14d: 11
  • Stars gained: 30d: 10
  • Stars gained: 90d: 25

Per-day formula: 0.40 × Hot today + 0.40 × Hot week + 0.20 × Breakout.

  • Same-day multiplier = stars 1d ÷ max(1, stars 7d ÷ 7)
  • Weekly multiplier = stars 7d ÷ max(1, stars 30d ÷ 30 × 7)
  • Fortnight multiplier = stars 14d ÷ max(1, stars 90d ÷ 90 × 14)
  • Hot today = clamp(70 × log-scale(stars 1d, 1000) + 30 × breakout-scale(same-day, 4))
  • Hot week = clamp(75 × log-scale(stars 7d, 5000) + 25 × breakout-scale(weekly, 3))
  • Breakout = clamp(35 × breakout-scale(same-day, 4) + 40 × breakout-scale(weekly, 3) + 25 × breakout-scale(fortnight, 2.5))
DateStarsStars 1dStars 7dStars 14dStars 30dStars 90dSame-day multiplierWeekly multiplierFortnight multiplierHot todayHot weekBreakoutStored score

Reliability score

Jul 19, 2026

Current36

Previous28

Weekly average

100500
Full metrics details

Derived from the displayed continuity, closure, shipping, liveness, and support-burden components.

180 observed daily rows. Missing days are not fabricated.

Reliability formula

30% Continuity + 30% Closure + 20% Shipping + 10% Liveness + 10% Support burden.

  • 30% Continuity: 31
  • 30% Closure: 60
  • 20% Shipping: 0
  • 10% Liveness: 100
  • 10% Support burden: 94

Per-day formula: 0.30 × Continuity + 0.30 × Closure + 0.20 × Shipping + 0.10 × Liveness + 0.10 × Support burden.

  • Continuity = 35% active ratio 90d + 20% active ratio 30d + 15% PR efficiency 90d + 10% PR efficiency 30d + 10% liveness + 10% observed-history coverage
  • Closure = 55% PR merge efficiency 90d + 45% issue close efficiency 90d
  • Shipping = 100 × (20% × release ratio 30d + 30% × release ratio 90d + 50% × release ratio 180d); ratios are releases ÷ 2, 6, and 12, capped at 1
  • Support burden = 100 − 2 × open issues per 1,000 stars
  • Liveness = 100 × exp(−pushed days ago ÷ 120)

Stars, issues, pull requests, and releases are daily observations. Pushed-days and license are repository snapshot-derived inputs and are not independent historical GitHub events.

DateIssues openedIssues closedPRs openedPRs mergedReleasesStarsOpen issuesPushed days agoContinuityClosureShippingLivenessSupport burdenLicenseObserved daysMissing daysNeeds healingStored score

Reliability breakdown

What drives the reliability score

Component scores measured daily from GitHub activity (2026-07-18).

Continuity30% of headline31

Activity on 10 of 90 tracked days in the last 90 and 4 of 30 in the last 30.

Closure30% of headline60

Merged 3 of 9 PRs opened and closed 1 of 1 issues opened over the last 90 tracked days — PR flow carries 55% of this component, issue flow 45%.

Shipping20% of headline0

0 releases in the last 180 days, 0 in the last 90 and 0 in the last 30 — a steady cadence scores highest.

Liveness10% of headline100

Last push 2 days ago — freshness decays as pushes age (roughly halves every 83 days without a push).

Support burden10% of headline94

128 open issues against 43,918 stars — about 3 open issues per 1,000 stars. Lighter backlogs score higher.

Adoption confidence59

Modeled — how confidently teams are adopting this repo. Stargazers

Maintenance quality48

Modeled from PR/issue responsiveness and upkeep signals. Activity pulse

Risk score26

Modeled — lower is better; adoption and continuity risk. Repository

Stays active (30d)40%

Modeled chance the repo stays active over 30 days. Activity pulse

Stays active (90d)50%

Modeled chance the repo stays active over 90 days. Activity pulse

Release rhythm (180d)0

Regularity of releases over the last 180 days. Releases

Maintainer bus risk (90d)64%

Modeled — lower is better; concentration of commits in few maintainers. Contributors graph

Topics

Explore related topics

Jump into the topic listings this repository belongs to.

Measured history

Project metrics

Weekly GitHub totals with 30, 90, and 180 day views.

Weekly star gains

Jul 19, 2026

Current6

Previous4

Weekly star gains

18-15-48
Full metrics details

GitHub GraphQL current stargazer cohort, reconstructed from starredAt events and totalCount retrieved in one stable pagination walk. GitHub does not expose historical unstar events, so this is not an exact ledger of past star counts.

180 observed daily rows. Missing days are not fabricated.

DateValue

Cumulative stars

Jul 19, 2026

Current43,915

Previous43,909

Cumulative total

43,91521,9580
Full metrics details

Running total of the GitHub GraphQL stargazer count over time (not weekly deltas), reconstructed from starredAt events and totalCount in one stable pagination walk. GitHub does not expose historical unstar events, so this is not an exact ledger of past star counts.

180 observed daily rows. Missing days are not fabricated.

DateValue

Issues opened

Jul 12, 2026

Current0

Previous0

Weekly total

210
Full metrics details

GitHub API observation. Historical values render only when the source provides a real observation for that day.

178 observed daily rows. Missing days are not fabricated.

DateValue

Issues closed

Jul 12, 2026

Current0

Previous0

Weekly total

210
Full metrics details

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

178 observed daily rows. Missing days are not fabricated.

DateValue

Pull requests opened

Jul 12, 2026

Current1

Previous0

Weekly total

840
Full metrics details

GitHub API observation. Historical values render only when the source provides a real observation for that day.

178 observed daily rows. Missing days are not fabricated.

DateValue

Pull requests closed

Jul 12, 2026

Current0

Previous0

Weekly total

950
Full metrics details

GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.

178 observed daily rows. Missing days are not fabricated.

DateValue

Pull requests merged

Jul 12, 2026

Current0

Previous0

Weekly total

740
Full metrics details

GitHub API observation. Historical values render only when the source provides a real observation for that day.

178 observed daily rows. Missing days are not fabricated.

DateValue

Issue close ratio (daily)

Jul 16, 2026

Current0.00

Daily ratio — a gap means nothing was opened that day

How this works: each day's value is issues closed that day ÷ issues opened that day. Days when nothing was opened render as gaps — never a rolling average or a made-up zero. Values above 1 mean the project closed more issues than arrived that day.

1.000.500.00
Full metrics details

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

6 observed daily rows. Missing days are not fabricated.

Per-day formula: issues closed that day ÷ issues opened that day; blank when nothing was opened (a gap, not a zero).

DateIssues openedIssues closedStored score

Pull request close ratio (daily)

Jul 18, 2026

Current1.00

Previous1.00

Daily ratio — a gap means nothing was opened that day

How this works: each day's value is pull requests closed that day ÷ pull requests opened that day. Days when nothing was opened render as gaps — never a rolling average or a made-up zero. Values above 1 mean the project closed more pull requests than arrived that day.

3.001.500.00
Full metrics details

GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.

40 observed daily rows. Missing days are not fabricated.

Per-day formula: pull requests closed that day ÷ pull requests opened that day; blank when nothing was opened (a gap, not a zero).

DatePRs openedPRs closedStored score

Project Overview

Retrofit is a type-safe HTTP client for Android and the JVM from Square. You define a Java or Kotlin interface, annotate methods with HTTP metadata, and let Retrofit turn those declarations into runtime API calls. You can use it for REST-style service integration, authenticated mobile API calls, and JVM service-to-service clients where you want strongly typed request and response models.

Retrofit is mature and focused. You get a clear abstraction for endpoint contracts, while your transport details still sit on top of OkHttp. That balance is useful when your team wants readable API boundaries without giving up lower-level network control.

Key Challenges Addressed

You often lose time when API code spreads raw URL building, serialization choices, and response parsing logic across many call sites. Retrofit targets that by centralizing endpoint contracts in annotated interfaces.

  • Interface-first API definitions keep request shape, path parameters, headers, and body models in one place.
  • Converter factories let you standardize JSON or other payload formats across your whole client layer.
  • Call adapter factories let you align execution style with your stack (for example synchronous calls, callbacks, or coroutine/Rx integrations).
  • OkHttp integration gives your team interceptors, connection pooling, TLS config, and retry controls at the transport layer.

Getting Started

You can start with a small interface and one Retrofit builder. A minimal workflow is to pick a converter, create a service interface, and execute one request.

interface RepoApi {
  @GET("repos/{owner}/{repo}")
  suspend fun repo(
    @Path("owner") owner: String,
    @Path("repo") repo: String
  ): RepoDto
}

val retrofit = Retrofit.Builder()
  .baseUrl("https://api.github.com/")
  .addConverterFactory(MoshiConverterFactory.create())
  .build()

val api = retrofit.create(RepoApi::class.java)
val result = api.repo("square", "retrofit")

You will hit sharp edges quickly if your base URL format is wrong, your converter does not match API payload shape, or your threading model is inconsistent with your chosen call adapter.

Features and Use Cases

Retrofit gives your team a strong contract layer over HTTP.

  • Annotated endpoints (@GET, @POST, @Path, @Query, @Body) for readable API contracts.
  • Pluggable converters for JSON and other encodings.
  • Pluggable call adapters so your app/service execution model stays consistent.
  • Per-method and global headers for auth and content negotiation.
  • Tight OkHttp interoperability for interceptors, logging, and connection behavior.

Common implementation patterns include Android app data layers, backend integrations in JVM services, and shared API modules where your team keeps endpoint definitions versioned and reviewed like any other interface contract.

Ecosystem and Dependencies

Retrofit depends on OkHttp for transport. That means your existing OkHttp interceptors, certificate pinning strategy, and timeout defaults carry over cleanly.

For serialization, you typically pair Retrofit with converters such as Moshi or Gson, based on your current model stack. For async style, you use call adapters aligned with your runtime choices so API calls fit naturally into your existing control flow.

When you compare alternatives, related projects you may evaluate include OkHttp, Ktor, Feign, Apache HttpComponents Client, and Volley.

Architectural Overview

Retrofit has a layered architecture:

  1. Interface contracts define endpoints and parameter mapping.
  2. Retrofit runtime parses annotations and builds request metadata.
  3. Converter layer serializes request bodies and deserializes responses.
  4. Call adapter layer maps raw calls into your chosen execution abstraction.
  5. OkHttp executes network I/O and connection management.

This design matters because you can swap serialization or async models without rewriting endpoint interfaces, and you can harden transport behavior in one place through OkHttp configuration.

Pros and Cons

  • Pros: You get clean, versionable API contracts that are easy to review and test.
  • Pros: Converter and call adapter extensions keep your core client layer adaptable as your stack changes.
  • Pros: OkHttp integration gives strong operational control for mobile and server JVM workloads.
  • Cons: Annotation-driven interfaces can hide runtime mapping errors until integration tests run.
  • Cons: Complex API shapes can require careful converter configuration and custom adapters.
  • Cons: If your team needs a full framework-level HTTP stack with server/client symmetry, Retrofit can feel narrower than broader platforms.

Comparison and Alternatives

Measured 90-day trends for this project and its alternatives.

GitHub stars

Weekly star gains

46,97223,462-48
Full metrics details

GitHub GraphQL current stargazer cohort, reconstructed from starredAt events and totalCount retrieved in one stable pagination walk. GitHub does not expose historical unstar events, so this is not an exact ledger of past star counts.

Retrofit

GitHub GraphQL current stargazer cohort, reconstructed from starredAt events and totalCount retrieved in one stable pagination walk. GitHub does not expose historical unstar events, so this is not an exact ledger of past star counts.

180 observed daily rows. Missing days are not fabricated.

DateValue
OkHttp

GitHub GraphQL current stargazer cohort, reconstructed from starredAt events and totalCount retrieved in one stable pagination walk. GitHub does not expose historical unstar events, so this is not an exact ledger of past star counts.

180 observed daily rows. Missing days are not fabricated.

DateValue
Ktor

GitHub GraphQL current stargazer cohort, reconstructed from starredAt events and totalCount retrieved in one stable pagination walk. GitHub does not expose historical unstar events, so this is not an exact ledger of past star counts.

41 observed daily rows. Missing days are not fabricated.

DateValue
Feign

GitHub GraphQL current stargazer cohort, reconstructed from starredAt events and totalCount retrieved in one stable pagination walk. GitHub does not expose historical unstar events, so this is not an exact ledger of past star counts.

43 observed daily rows. Missing days are not fabricated.

DateValue
Apache HttpComponents Client

GitHub GraphQL current stargazer cohort, reconstructed from starredAt events and totalCount retrieved in one stable pagination walk. GitHub does not expose historical unstar events, so this is not an exact ledger of past star counts.

42 observed daily rows. Missing days are not fabricated.

DateValue

Issues opened

Weekly total

110
Full metrics details

GitHub API observation. Historical values render only when the source provides a real observation for that day.

Retrofit

GitHub API observation. Historical values render only when the source provides a real observation for that day.

178 observed daily rows. Missing days are not fabricated.

DateValue
OkHttp

GitHub API observation. Historical values render only when the source provides a real observation for that day.

36 observed daily rows. Missing days are not fabricated.

DateValue

Issues closed

Weekly total

110
Full metrics details

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

Retrofit

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

178 observed daily rows. Missing days are not fabricated.

DateValue
OkHttp

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

36 observed daily rows. Missing days are not fabricated.

DateValue

Pull requests opened

Weekly total

210
Full metrics details

GitHub API observation. Historical values render only when the source provides a real observation for that day.

Retrofit

GitHub API observation. Historical values render only when the source provides a real observation for that day.

178 observed daily rows. Missing days are not fabricated.

DateValue
OkHttp

GitHub API observation. Historical values render only when the source provides a real observation for that day.

36 observed daily rows. Missing days are not fabricated.

DateValue

Pull requests closed

Weekly total

210
Full metrics details

GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.

Retrofit

GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.

178 observed daily rows. Missing days are not fabricated.

DateValue
OkHttp

GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.

36 observed daily rows. Missing days are not fabricated.

DateValue

Pull requests merged

Weekly total

110
Full metrics details

GitHub API observation. Historical values render only when the source provides a real observation for that day.

Retrofit

GitHub API observation. Historical values render only when the source provides a real observation for that day.

178 observed daily rows. Missing days are not fabricated.

DateValue
OkHttp

GitHub API observation. Historical values render only when the source provides a real observation for that day.

36 observed daily rows. Missing days are not fabricated.

DateValue

Open/closed pull request ratio

Weekly average

100500
Full metrics details

GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.

Retrofit

GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.

180 observed daily rows. Missing days are not fabricated.

DateValue
OkHttp

GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.

180 observed daily rows. Missing days are not fabricated.

DateValue
Ktor

GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.

41 observed daily rows. Missing days are not fabricated.

DateValue
Feign

GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.

43 observed daily rows. Missing days are not fabricated.

DateValue
Apache HttpComponents Client

GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.

42 observed daily rows. Missing days are not fabricated.

DateValue

Open/closed issues ratio

Weekly average

100500
Full metrics details

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

Retrofit

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

180 observed daily rows. Missing days are not fabricated.

DateValue
OkHttp

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

180 observed daily rows. Missing days are not fabricated.

DateValue
Ktor

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

41 observed daily rows. Missing days are not fabricated.

DateValue
Feign

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

43 observed daily rows. Missing days are not fabricated.

DateValue
Apache HttpComponents Client

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

42 observed daily rows. Missing days are not fabricated.

DateValue

Releases

Weekly total

110
Full metrics details

GitHub release published_at events bucketed by UTC day; drafts are excluded.

Retrofit

GitHub release published_at events bucketed by UTC day; drafts are excluded.

180 observed daily rows. Missing days are not fabricated.

DateValue
OkHttp

GitHub release published_at events bucketed by UTC day; drafts are excluded.

180 observed daily rows. Missing days are not fabricated.

DateValue
Ktor

GitHub release published_at events bucketed by UTC day; drafts are excluded.

41 observed daily rows. Missing days are not fabricated.

DateValue
Feign

GitHub release published_at events bucketed by UTC day; drafts are excluded.

43 observed daily rows. Missing days are not fabricated.

DateValue
Apache HttpComponents Client

GitHub release published_at events bucketed by UTC day; drafts are excluded.

42 observed daily rows. Missing days are not fabricated.

DateValue

Hotness score

Weekly average

100500
Full metrics details

Derived only from GitHub GraphQL starredAt events after daily star totals are reconciled.

Retrofit

Derived only from GitHub GraphQL starredAt events after daily star totals are reconciled.

180 observed daily rows. Missing days are not fabricated.

Per-day formula: 0.40 × Hot today + 0.40 × Hot week + 0.20 × Breakout.

  • Same-day multiplier = stars 1d ÷ max(1, stars 7d ÷ 7)
  • Weekly multiplier = stars 7d ÷ max(1, stars 30d ÷ 30 × 7)
  • Fortnight multiplier = stars 14d ÷ max(1, stars 90d ÷ 90 × 14)
  • Hot today = clamp(70 × log-scale(stars 1d, 1000) + 30 × breakout-scale(same-day, 4))
  • Hot week = clamp(75 × log-scale(stars 7d, 5000) + 25 × breakout-scale(weekly, 3))
  • Breakout = clamp(35 × breakout-scale(same-day, 4) + 40 × breakout-scale(weekly, 3) + 25 × breakout-scale(fortnight, 2.5))
DateStarsStars 1dStars 7dStars 14dStars 30dStars 90dSame-day multiplierWeekly multiplierFortnight multiplierHot todayHot weekBreakoutStored score
OkHttp

Derived only from GitHub GraphQL starredAt events after daily star totals are reconciled.

180 observed daily rows. Missing days are not fabricated.

Per-day formula: 0.40 × Hot today + 0.40 × Hot week + 0.20 × Breakout.

  • Same-day multiplier = stars 1d ÷ max(1, stars 7d ÷ 7)
  • Weekly multiplier = stars 7d ÷ max(1, stars 30d ÷ 30 × 7)
  • Fortnight multiplier = stars 14d ÷ max(1, stars 90d ÷ 90 × 14)
  • Hot today = clamp(70 × log-scale(stars 1d, 1000) + 30 × breakout-scale(same-day, 4))
  • Hot week = clamp(75 × log-scale(stars 7d, 5000) + 25 × breakout-scale(weekly, 3))
  • Breakout = clamp(35 × breakout-scale(same-day, 4) + 40 × breakout-scale(weekly, 3) + 25 × breakout-scale(fortnight, 2.5))
DateStarsStars 1dStars 7dStars 14dStars 30dStars 90dSame-day multiplierWeekly multiplierFortnight multiplierHot todayHot weekBreakoutStored score
Ktor

Derived only from GitHub GraphQL starredAt events after daily star totals are reconciled.

41 observed daily rows. Missing days are not fabricated.

Per-day formula: 0.40 × Hot today + 0.40 × Hot week + 0.20 × Breakout.

  • Same-day multiplier = stars 1d ÷ max(1, stars 7d ÷ 7)
  • Weekly multiplier = stars 7d ÷ max(1, stars 30d ÷ 30 × 7)
  • Fortnight multiplier = stars 14d ÷ max(1, stars 90d ÷ 90 × 14)
  • Hot today = clamp(70 × log-scale(stars 1d, 1000) + 30 × breakout-scale(same-day, 4))
  • Hot week = clamp(75 × log-scale(stars 7d, 5000) + 25 × breakout-scale(weekly, 3))
  • Breakout = clamp(35 × breakout-scale(same-day, 4) + 40 × breakout-scale(weekly, 3) + 25 × breakout-scale(fortnight, 2.5))
DateStarsStars 1dStars 7dStars 14dStars 30dStars 90dSame-day multiplierWeekly multiplierFortnight multiplierHot todayHot weekBreakoutStored score
Feign

Derived only from GitHub GraphQL starredAt events after daily star totals are reconciled.

43 observed daily rows. Missing days are not fabricated.

Per-day formula: 0.40 × Hot today + 0.40 × Hot week + 0.20 × Breakout.

  • Same-day multiplier = stars 1d ÷ max(1, stars 7d ÷ 7)
  • Weekly multiplier = stars 7d ÷ max(1, stars 30d ÷ 30 × 7)
  • Fortnight multiplier = stars 14d ÷ max(1, stars 90d ÷ 90 × 14)
  • Hot today = clamp(70 × log-scale(stars 1d, 1000) + 30 × breakout-scale(same-day, 4))
  • Hot week = clamp(75 × log-scale(stars 7d, 5000) + 25 × breakout-scale(weekly, 3))
  • Breakout = clamp(35 × breakout-scale(same-day, 4) + 40 × breakout-scale(weekly, 3) + 25 × breakout-scale(fortnight, 2.5))
DateStarsStars 1dStars 7dStars 14dStars 30dStars 90dSame-day multiplierWeekly multiplierFortnight multiplierHot todayHot weekBreakoutStored score
Apache HttpComponents Client

Derived only from GitHub GraphQL starredAt events after daily star totals are reconciled.

42 observed daily rows. Missing days are not fabricated.

Per-day formula: 0.40 × Hot today + 0.40 × Hot week + 0.20 × Breakout.

  • Same-day multiplier = stars 1d ÷ max(1, stars 7d ÷ 7)
  • Weekly multiplier = stars 7d ÷ max(1, stars 30d ÷ 30 × 7)
  • Fortnight multiplier = stars 14d ÷ max(1, stars 90d ÷ 90 × 14)
  • Hot today = clamp(70 × log-scale(stars 1d, 1000) + 30 × breakout-scale(same-day, 4))
  • Hot week = clamp(75 × log-scale(stars 7d, 5000) + 25 × breakout-scale(weekly, 3))
  • Breakout = clamp(35 × breakout-scale(same-day, 4) + 40 × breakout-scale(weekly, 3) + 25 × breakout-scale(fortnight, 2.5))
DateStarsStars 1dStars 7dStars 14dStars 30dStars 90dSame-day multiplierWeekly multiplierFortnight multiplierHot todayHot weekBreakoutStored score

Reliability score

Weekly average

100500
Full metrics details

Derived from the displayed continuity, closure, shipping, liveness, and support-burden components.

Retrofit

Derived from the displayed continuity, closure, shipping, liveness, and support-burden components.

180 observed daily rows. Missing days are not fabricated.

Per-day formula: 0.30 × Continuity + 0.30 × Closure + 0.20 × Shipping + 0.10 × Liveness + 0.10 × Support burden.

  • Continuity = 35% active ratio 90d + 20% active ratio 30d + 15% PR efficiency 90d + 10% PR efficiency 30d + 10% liveness + 10% observed-history coverage
  • Closure = 55% PR merge efficiency 90d + 45% issue close efficiency 90d
  • Shipping = 100 × (20% × release ratio 30d + 30% × release ratio 90d + 50% × release ratio 180d); ratios are releases ÷ 2, 6, and 12, capped at 1
  • Support burden = 100 − 2 × open issues per 1,000 stars
  • Liveness = 100 × exp(−pushed days ago ÷ 120)

Stars, issues, pull requests, and releases are daily observations. Pushed-days and license are repository snapshot-derived inputs and are not independent historical GitHub events.

DateIssues openedIssues closedPRs openedPRs mergedReleasesStarsOpen issuesPushed days agoContinuityClosureShippingLivenessSupport burdenLicenseObserved daysMissing daysNeeds healingStored score
OkHttp

Derived from the displayed continuity, closure, shipping, liveness, and support-burden components.

180 observed daily rows. Missing days are not fabricated.

Per-day formula: 0.30 × Continuity + 0.30 × Closure + 0.20 × Shipping + 0.10 × Liveness + 0.10 × Support burden.

  • Continuity = 35% active ratio 90d + 20% active ratio 30d + 15% PR efficiency 90d + 10% PR efficiency 30d + 10% liveness + 10% observed-history coverage
  • Closure = 55% PR merge efficiency 90d + 45% issue close efficiency 90d
  • Shipping = 100 × (20% × release ratio 30d + 30% × release ratio 90d + 50% × release ratio 180d); ratios are releases ÷ 2, 6, and 12, capped at 1
  • Support burden = 100 − 2 × open issues per 1,000 stars
  • Liveness = 100 × exp(−pushed days ago ÷ 120)

Stars, issues, pull requests, and releases are daily observations. Pushed-days and license are repository snapshot-derived inputs and are not independent historical GitHub events.

DateIssues openedIssues closedPRs openedPRs mergedReleasesStarsOpen issuesPushed days agoContinuityClosureShippingLivenessSupport burdenLicenseObserved daysMissing daysNeeds healingStored score
Ktor

Derived from the displayed continuity, closure, shipping, liveness, and support-burden components.

41 observed daily rows. Missing days are not fabricated.

Per-day formula: 0.30 × Continuity + 0.30 × Closure + 0.20 × Shipping + 0.10 × Liveness + 0.10 × Support burden.

  • Continuity = 35% active ratio 90d + 20% active ratio 30d + 15% PR efficiency 90d + 10% PR efficiency 30d + 10% liveness + 10% observed-history coverage
  • Closure = 55% PR merge efficiency 90d + 45% issue close efficiency 90d
  • Shipping = 100 × (20% × release ratio 30d + 30% × release ratio 90d + 50% × release ratio 180d); ratios are releases ÷ 2, 6, and 12, capped at 1
  • Support burden = 100 − 2 × open issues per 1,000 stars
  • Liveness = 100 × exp(−pushed days ago ÷ 120)

Stars, issues, pull requests, and releases are daily observations. Pushed-days and license are repository snapshot-derived inputs and are not independent historical GitHub events.

DateIssues openedIssues closedPRs openedPRs mergedReleasesStarsOpen issuesPushed days agoContinuityClosureShippingLivenessSupport burdenLicenseObserved daysMissing daysNeeds healingStored score
Feign

Derived from the displayed continuity, closure, shipping, liveness, and support-burden components.

43 observed daily rows. Missing days are not fabricated.

Per-day formula: 0.30 × Continuity + 0.30 × Closure + 0.20 × Shipping + 0.10 × Liveness + 0.10 × Support burden.

  • Continuity = 35% active ratio 90d + 20% active ratio 30d + 15% PR efficiency 90d + 10% PR efficiency 30d + 10% liveness + 10% observed-history coverage
  • Closure = 55% PR merge efficiency 90d + 45% issue close efficiency 90d
  • Shipping = 100 × (20% × release ratio 30d + 30% × release ratio 90d + 50% × release ratio 180d); ratios are releases ÷ 2, 6, and 12, capped at 1
  • Support burden = 100 − 2 × open issues per 1,000 stars
  • Liveness = 100 × exp(−pushed days ago ÷ 120)

Stars, issues, pull requests, and releases are daily observations. Pushed-days and license are repository snapshot-derived inputs and are not independent historical GitHub events.

DateIssues openedIssues closedPRs openedPRs mergedReleasesStarsOpen issuesPushed days agoContinuityClosureShippingLivenessSupport burdenLicenseObserved daysMissing daysNeeds healingStored score
Apache HttpComponents Client

Derived from the displayed continuity, closure, shipping, liveness, and support-burden components.

42 observed daily rows. Missing days are not fabricated.

Per-day formula: 0.30 × Continuity + 0.30 × Closure + 0.20 × Shipping + 0.10 × Liveness + 0.10 × Support burden.

  • Continuity = 35% active ratio 90d + 20% active ratio 30d + 15% PR efficiency 90d + 10% PR efficiency 30d + 10% liveness + 10% observed-history coverage
  • Closure = 55% PR merge efficiency 90d + 45% issue close efficiency 90d
  • Shipping = 100 × (20% × release ratio 30d + 30% × release ratio 90d + 50% × release ratio 180d); ratios are releases ÷ 2, 6, and 12, capped at 1
  • Support burden = 100 − 2 × open issues per 1,000 stars
  • Liveness = 100 × exp(−pushed days ago ÷ 120)

Stars, issues, pull requests, and releases are daily observations. Pushed-days and license are repository snapshot-derived inputs and are not independent historical GitHub events.

DateIssues openedIssues closedPRs openedPRs mergedReleasesStarsOpen issuesPushed days agoContinuityClosureShippingLivenessSupport burdenLicenseObserved daysMissing daysNeeds healingStored score

If your team wants stricter transport control with less abstraction, OkHttp is closer to raw HTTP primitives. If you want a broader Kotlin-first application stack, Ktor can cover more than client calls. If you want declarative Java clients oriented around service contracts in microservice environments, Feign is a common path. Apache HttpComponents Client gives low-level, mature HTTP building blocks. Volley stays relevant for specific Android networking and caching patterns.

Project Repo Adoption confidence (~6mo) PRs merged (~6mo) Star growth (~6mo)
Retrofit https://github.com/square/retrofit 68.50 279 896
OkHttp https://github.com/square/okhttp metrics pending 0 metrics pending
Ktor https://github.com/ktorio/ktor metrics pending 0 metrics pending
Feign https://github.com/OpenFeign/feign metrics pending 0 metrics pending
Apache HttpComponents Client https://github.com/apache/httpcomponents-client metrics pending 0 metrics pending
Volley https://github.com/google/volley metrics pending 0 metrics pending

OkHttp is the best overall alternative when you want maximum transport-level control and long-term ecosystem maturity while staying close to Retrofit-compatible patterns.

Conclusion

Retrofit is strongest when your team wants clean, type-safe HTTP contracts on Android or JVM without building a client framework from scratch. You gain a durable interface-first API layer, but you still need disciplined converter setup and integration tests for mapping correctness. Your most important operational takeaway is to treat Retrofit and OkHttp as one client system and standardize config, interceptors, and error handling centrally using the official repository, documentation, and community issue tracker.

Join the conversation

Reviews · Questions · Posts

Share what you know about retrofit — write a review from your real experience, ask an implementation question, or publish a post about how you use it.

Share your experience

Write or update your review

Explain what worked, what broke down, and what another team should know before adopting retrofit.

Write your review now — it saves locally and publishes automatically after you sign in.

Rating
Positive attributes
Negative attributes

Project Q&A

Questions and answers

Browse implementation threads tied directly to lysine-dev/retrofit. Each question links through to the full answer page.

Q&A No threads yet

Be the first to ask how teams run retrofit in production. Every question you post becomes a durable, searchable answer page other developers can find.

Ask the first question

Related posts

Posts tagged with the same topics

These posts come from the same topic surface as this repo, so readers can move from project evaluation into practical writeups and migration notes without leaving context.

Posts No topic-linked posts yet

Share how your team uses retrofit — a migration note, an architecture writeup, or a comparison. Your post reaches everyone browsing these same topics.

Write the first post
Get a weekly email with the hottest new projects in the Mobile Development and Java world.
No Spam. Unsubscribe easily at any time.

Copyright 2018-2026 Awesome Open Source.  All rights reserved.