Proposal: Make preview features configurable
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 25/100
Rechercherichtung
Beginne damit nachzuverfolgen, wie standardmäßige Preview-Accept-Header und ListOptions behandelt werden; das Issue nennt keine Dateien oder Tests. Definiere die RequestOptions-API und kläre, wie neue APIs mit Preview-Headern umgehen sollten, und überprüfe anschließend, dass Requests zum Auflisten von Repositories den unerwünschten Header weglassen können.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Problem
A project I'm working on has an issue where a list of repos is returning a Server Error due to an additional Accept header being added (The "mediaTypeCodesOfConductPreview" header).
Removing this header fixes the problem but I can't do this with the current library implementation.
Solution
Instead of adding these headers by default, we could move them to an Options parameter similar to ListOptions.
type RequestOptions {
acceptHeaders []string
}
Pros
- Allows developers to control which headers to add (including headers the library may not control)
- Removes the maintenance of adding / removing headers from library owners
- Opens the door for any additional request options in the future.
- This will remove the need for comments like
// TODO: remove custom Accept headers when APIs fully launch.
Cons
- Forces users to care about headers
- While a con, users should know if a feature they are using is preview or not and subject to change
Concerns
The only major concern I have with this is approach is that it gets fuzzy what to do with entirely new API's (for example the checks API).
For consistency the API could still require the developer to add the header.
For a sane API the API could add the header with the expectation that the header is removed as soon as possible, but again moves the burden on to the library.
- Vorherrschende Sprache
- Go
- Sterne
- 11.3k
- Forks
- 2.5k
- Ø Merge
- 1 T. 16 Std.
- Gemergte PRs (30 T.)
- 51
Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus google/go-github
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 68/100
-
google/go-github#4583 · 2 Kommentare · 1 Reaktion · 1 zugewiesene Person ·
-
google/go-github#4526 · 1 Kommentar · 1 Reaktion · 1 zugewiesene Person ·
Alle Issues in google/go-github
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
bazel-contrib/rules_go#4726 · 1 Kommentar ·
-
area/auto-scaling area/monitoring area/ops-productivity kind/enhancement
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 74/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
-
Type/Improvement
Schwierigkeit 1/5 1-3 Stunden Anfängerfreundlichkeit 90/100
OpenNSW/nsw-srilanka#522 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 92/100