Forskelle mellem API, framework og bibliotek forklaret enkelt

Når du starter i programmering Det er meget nemt at blive forvirret af begreber som bibliotek, framework og APIVed første øjekast virker de som forskellige betegnelser for den samme ting: "kode, der allerede er skrevet af andre, som du bruger i dine projekter." Men i virkeligheden udfylder hver enkelt en specifik rolle inden for softwareudvikling.

Hvis du har programmeret i et stykke tid, bruger du det sandsynligvis dagligt. API'er, frameworks og biblioteker Uden at tænke for meget over det, kan du endda føle, at du interagerer med alle på samme måde: du importerer noget, kalder funktioner, og det er det. Alligevel hjælper en fuld forståelse af, hvad hver ting er, og hvordan de relaterer sig, dig med at vælge bedre værktøjer, designe dine projekter bedre og kommunikere med andre udviklere uden forvirring.

Hvad er et bibliotek i programmering?

en software bibliotek Det er i bund og grund et sæt kode designet til genbrug: funktioner, klasser, datatyper og værktøjer, som nogen har grupperet sammen for at løse specifikke problemer. I stedet for at skrive alt fra bunden importerer du biblioteket og udnytter det arbejde, der allerede er udført og testet.

Hovedformålet med et bibliotek er levere funktionalitet fra starten som du kan indarbejde i dine programmer uden at skulle "genopfinde hjulet". Det er normalt skabt af folk med omfattende erfaring inden for et bestemt område (f.eks. matematik, adgang til databaser(tekstbehandling, grafik…) og pakker det på en måde, der gør det nemt for andre udviklere at integrere det.

Et velkendt eksempel i JavaScript-økosystemet er LodashDette bibliotek tilbyder tonsvis af hjælpefunktioner til at arbejde med arrays, objekter, strenge, funktioner og samlinger Generelt set, i stedet for at skrive dine egne filtre, transformationer eller avancerede søgninger, kalder du bare Lodashs funktioner, og så er du færdig, med mindre kode og færre fejl.

I verden Python vi har nussetEn nøglekomponent til numerisk beregning. Den leverer datastrukturer som den berømte flerdimensionelle arrays og yderst effektive vektoriserede operationer til avanceret matematik og datalogi. Uden NumPy ville det være en prøvelse at skrive al den matrixmanipulation og lineære algebraoperationer i hånden.

I Java kan man nævne Apache CommonsEn familie af biblioteker med alle mulige værktøjer: avancerede samlinger, filhåndtering, typekonvertering, strengmanipulation og meget mere. Takket være disse biblioteker, genbrug robuste løsninger i stedet for at opdatere din egen kode igen og igen.

Når det siges, at et bibliotek hjælper med at gøre din kode "modulær", betyder det, at din applikation er bygget på basis af uafhængige og genanvendelige deleDette fremmer organisering, letter vedligeholdelse og gør det muligt for systemet at skalere til mere data og mere belastning med mindre afbrydelser.

En meget simpel måde at tænke på det er at forestille sig, at dit projekt er en værktøjskasse: et bibliotek er som et specialiseret værktøjFor eksempel en tømrerhammer. Den tvinger dig ikke til at bygge huset på en bestemt måde; den giver dig blot et rigtig godt værktøj til at hamre søm i, når du beslutter dig for at bruge den.

Hvad er et framework, og hvordan adskiller det sig fra et bibliotek?

Un rammer Det er noget større og mere struktureret end et bibliotek. Det er en samling af værktøjer, biblioteker, regler og konventioner der giver dig et fundament for at udvikle komplette applikationer hurtigere og mere effektivt.

Hvis et bibliotek er et selvstændigt værktøj, er et framework mere som en plantegning af en bygning, hvor en del af strukturen allerede er opførtDu ankommer, følger tegningen og færdiggør resten af ​​konstruktionen. Frameworket definerer den overordnede arkitektur og fortæller dig, hvor hvert stykke af din kode passer ind.

I et framework importerer du ikke bare funktioner: du accepterer at arbejde efter disse retningslinjer. en arbejdsgang og mønstre Frameworket bestemmer mange ting for dig (hvordan filer organiseres, hvordan anmodninger håndteres, hvilke livscyklusser du skal respektere...), og du tilpasser dig den "lykkelige vej", det foreslår.

Et centralt træk, der ofte bruges til at forklare forskellen, er den såkaldte inversion af kontrolMed et bibliotek bestemmer du, hvornår du vil kalde det. Med et framework kalder frameworket i mange tilfælde selv din kode på de passende tidspunkter (for eksempel når en HTTP-anmodning ankommer, når en komponent initialiseres, eller når en hændelse indtræffer).

Vi kan sammenligne det med en opskriftsbogOpskriften giver dig allerede ingredienslisten, rækkefølgen af ​​trinene og tilberedningstiden. Du skal kun tilføje de sidste detaljer og justere den efter din smag, men strukturen er allerede defineret. På samme måde guider et rammeværk dig i, hvordan du opbygger din applikation.

Når man arbejder med et framework, er den store fordel, at man kan fokus på forretningslogik (hvad der gør din applikation unik) uden at spilde tid på altid at opsætte den samme grundlæggende infrastruktur: routing, databaseforbindelse, sikkerhed, skabeloner osv.

Nogle meget populære frameworks inden for webudvikling er Django (til Python), Ruby on Rails (for Ruby), Laravel (til PHP) eller Forår (til Java). Disse frameworks vælges normalt baseret på mest brugte sprogDe tilbyder alle meget komplette strukturer, der kombinerer biblioteker, interne API'er og linjeværktøjer. kommandoer og klare konventioner for organisering af dit projekt.

På frontend-siden finder vi "store" frameworks og biblioteker som f.eks. Angular, React eller Vue.js som, udover genanvendelige komponenter, foreslår meget definerede arkitekturer og flows til opbygning af komplekse grænseflader.

Hvad er en API, og hvorfor er den så vigtig?

en API (Application Programming Interface) er ikke så meget et specifikt stykke kode som en kontrakt, der beskriver, hvordan to softwareprogrammer kommunikererDefiner hvilke operationer der kan udføres, hvilke data der skal sendes, og hvad svaret vil være.

Tænk på API'en som brugsanvisning Dette forklarer, hvordan man bruger et biblioteks funktioner, eller hvordan man kommunikerer med en fjerntjeneste. Du behøver ikke at kende de interne implementeringsdetaljer; du skal blot følge API-reglerne (de tilgængelige metoder, parametre og dataformater).

For at visualisere dette, forestil dig, at du ønsker, at din applikation skal give landmænd besked, når den ændrer sig El tiempoDu kunne oprette dit eget vejrudsigtssystem (hvilket ville være vanvittigt) eller opret forbindelse til API'en fra en specialiseret tjeneste, såsom OpenWeather, der allerede leverer disse oplysninger. Din app foretager en anmodning i henhold til API-reglerne og modtager dataene klar til brug.

I denne fase Du ved kun, hvad API'en lover digFor eksempel, "hvis du sender mig en by og en adgangsnøgle, returnerer jeg en JSON-fil med temperatur, luftfugtighed og prognose." Resten – hvordan de beregner disse data, hvordan de har konfigureret deres infrastruktur, hvilke algoritmer de bruger – er skjult bag API'en.

En API kan være den synlige del af et bibliotek eller et framework (f.eks. Django- eller NumPy-klasse- og metode-API'en), eller den kan være en fjerngrænseflade til et eksternt system, såsom API'en for Google Kort, YouTube API eller PayPal API.

I webverdenen, når vi taler om "web-API'er", mener vi normalt grænseflader tilgængelige via HTTP (REST, GraphQL osv.), der typisk returnerer data i JSON-format. Disse API'er tillader meget forskellige systemer (mobil, web, backend-tjenester) at integrere med hinanden uanset det underliggende sprog eller den underliggende teknologi.

API versus bibliotek: to komplementære dele

Mange bruger "API" og "bibliotek" næsten i flæng, men det er de ikke. et bibliotek er konkret kode, virkelige implementeringer af funktioner og klasser, som du kan downloade og indarbejde i dit projekt.

API'en er derimod specifikationen af, hvordan biblioteket brugesDet er den offentlige liste over metoder, klasser, parametre og returtyper, som dit program kan tilgå. I værktøjskassens analogi ville biblioteket være det fysiske sæt af værktøjer, og API'en ville være det katalog, der forklarer, hvad hvert værktøj gør, og hvordan man bruger det korrekt.

Noget meget vigtigt: en enkelt API kan have flere implementeringer i form af separate biblioteker. For eksempel definerer en specifikation som JDBC i Java, hvordan man interagerer med databaser; derefter tilbyder hver udbyder (PostgreSQL, MySQL osv.) sit eget bibliotek, der implementerer den pågældende API.

Takket være denne adskillelse kan du skrive dit program mod en Stabil og veldesignet API og ændre det underliggende bibliotek uden at omskrive al koden. Det er en af ​​nøglerne til portabilitet og interoperabilitet i software.

Kort sagt, når descargas Noget i retning af JavaMail, NumPy eller Apache Commons – det du får er... biblioteker, der implementerer et APIDu programmerer "mod API'en" (hvad de offentlige metoder lover) og stoler på, at den interne implementering vil udføre arbejdet effektivt og korrekt.

Hvordan passer rammerne ind i alt dette?

masse rammer De kombinerer typisk flere biblioteker og en bred vifte af API'er under én struktur. Udover at tilbyde genanvendelig kode, leverer de også et komplet skelet at bygge applikationer efter en ensartet tilgang.

En typisk ramme inkorporerer:

• Interne biblioteker til almindelige opgaver (godkendelse, dataadgang, skabeloner, valideringer osv.).
• Proprietære API'er der præsenterer disse evner på en ordnet og veldokumenteret måde.
• Yderligere værktøjer såsom kodegeneratorer, debuggere, visuelle miljøer eller integrerede editorer.

Et meget grafisk eksempel er Unity3D i udviklingen af spilDet er ikke bare et grafikbibliotek: det er et komplet framework med en visuel editor, fysikmotor, scenesystem, debugging, pakning og utallige API'er til lyd, animation, brugerinput og meget mere. Det giver dig stort set alt, hvad du behøver for at lave et spil, så længe du følger retningslinjerne. mønstre og arbejdsgange som Enheden selv etablerer.

I webudvikling indebærer brugen af ​​et framework som Django eller Laravel at anvende dets mental model og dens projektstrukturDine views, modeller, controllere og skabeloner passer ind i de steder og formater, som frameworket forventer, og til gengæld gør det dit liv meget lettere med administrationsværktøjer, databasemigreringer, routing og meget mere.

Fra et API-perspektiv kan et framework både forbruge eksterne API'er (for eksempel en betalingsudbyders API) såsom Vis din egen API så andre applikationer kan interagere med dit system. Det er meget almindeligt at kombinere et webframework med et REST API-orienteret subframework for at skabe rene og vedligeholdelsesvenlige grænseflader.

Praktiske forskelle mellem bibliotek, framework og API

Efter alle disse definitioner er det værd at omsætte dem til praksis. praktiske forskelle som du vil bemærke i din hverdag som udvikler.

Et bibliotek:

• Giver dig brugsklare funktioner eller klasser til at løse specifikke problemer (f.eks. datohåndtering, PDF-generering, krypteringsalgoritmer).
• Den definerer ikke en global arkitektur for din applikation. Du bestemmer, hvordan projektet skal organiseres og hvornår man skal ringe til biblioteket.
• Det kan bruges i kombination med mange andre biblioteker uden at skulle forpligte sig til en enkelt tilgang.

En ramme:

• tilbyder dig en grundlæggende struktur for udvikling af komplette applikationer (især web og mobil, men også desktop eller spil).
• Det pålægger en vis orden og mønstre (for eksempel MVC, MVVM eller lagdelt arkitektur), som du skal respektere, så alt passer sammen.
• Det giver dig mulighed for at være mere produktiv på gentagne opgaver (routing, sikkerhed, skabeloner osv.) til gengæld for at acceptere en læringskurve større og mindre absolut frihed.

En API:

• Definere hvordan softwarekomponenter kommunikererhvad enten det er inden for din applikation (biblioteks-API) eller mellem applikationer (web-API, operativsystem-API, SaaS-platform-API).
• Det er ikke nødvendigvis koden i sig selv, men et sæt regler (slutpunkter, parametre, datatyper, fejlkoder).
• Det gør det muligt for meget forskellige systemer at arbejde sammen uden at kende deres interne detaljer.

F.eks Google Maps API Det giver dig mulighed for at integrere interaktive kort og geoplaceringsfunktioner i dine web- eller mobilapplikationer. API'en til YouTube Det giver dig mulighed for at se videoer, kanaler og afspilningslister, samt interagere med noget af indholdet fra dine egne tjenester.

Hvorfor udgiver virksomheder deres API'er?

Mange virksomheder beslutter at "åbne" eller udgive deres API'er, så andre udviklere bygger oven på deres tjenesterVed at gøre dette eksponerer de bestemte adgangspunkter til deres system (selvfølgelig beskyttet af godkendelse og tilladelser) og giver tredjeparter mulighed for at udvide platformens rækkevidde.

De vigtigste årsager For at udgive en API tages følgende trin normalt:

• udvidelsesmuligheder: giver andre mulighed for at tilføje nye funktioner, integrationer og anvendelser, som virksomheden måske ikke selv havde forestillet sig.
• Økosystemopbygningat fremme et miljø af komplementære applikationer og tjenester, der øge værdien af ​​hovedproduktet.
• åben innovation: lad lokalsamfundet eksperimentere og foreslå kreative løsninger, hvilket ofte genererer nye forretningsidéer.
• forretningsintegrationat lette tjenestens forbindelse til CRM'er, ERP'er, marketingværktøjer og andre interne applikationer i virksomheder.
• Markedsudvidelsenå ud til brugere og nicher, som basisplatformen ikke ville nå alene, takket være integrationer skabt af tredjeparter.

Et meget synligt eksempel er hele økosystemet af værktøjer omkring WhatsApp Virksomhed og dens API'ersom tillader opbygning af "multi-agent"-platforme, så flere operatører kan betjene kunder fra et enkelt nummer, integrere det med CRM, tilføje chatbots, automatisere svar osv. Her fungerer WhatsApp API'en som hoveddør til messaging-infrastrukturen, og flere kommercielle og open source-løsninger bygger ovenpå den med avancerede funktionaliteter.

Hvad gør en API "god"

Ikke alle API'er er lige veludviklede. godt API-design Det gør en stor forskel i oplevelsen for den udvikler, der bruger det, og i hvor nemt det er at vedligeholde langsigtede integrationer.

Nogle nøglefunktioner Karakteristikaene for et kvalitets-API er:

• klarhedMetodenavne, stier og parametre, der er forståelige med det samme; ingen tvetydigheder.
• konsistenssamme navngivningsregler, lignende svarstrukturer og homogene mønstre i hele API'en.
• Omhyggelig dokumentationTrinvise vejledninger, kodeeksempler, forklaring af hvert slutpunkt og mulige fejl.
• stabilitetKontrollerede ændringer, tydeligt markerede versioner og bagudkompatibilitet for at undgå at eksisterende applikationer ødelægges natten over.
• God præstationHurtige og effektive svar med hensyn til ressourceforbrug, især i web-API'er, der er eksponeret til internettet.
• stærk sikkerhedautentificering, autorisation, kryptering og veldesignede adgangskontroller.
• Nyttig fejlhåndteringBeskrivende fejlmeddelelser og tydelige statuskoder for at lette diagnosen.

I tilfælde af moderne web-API'er er standardformatet til udveksling af data JSONfordi det er let, nemt for mennesker at læse og meget nemt at parse fra næsten ethvert programmeringssprog.

Typer af API'er, du vil støde på

Begrebet API er meget bredt og gælder for flere niveauer af stakken af software. Nogle almindelige typer er:

• Operativsystem-API'erDisse gør det muligt for applikationer at kommunikere med det underliggende system (filhåndtering, processer, hukommelse, netværk osv.). Eksempler: API'en for Windows eller POSIX-specifikationen i typesystemer Unix.
• Fjernstyrede eller distribuerede API'erDe definerer, hvordan programmer, der kører på forskellige maskiner, kommunikerer. De bruger specifikke netværksprotokoller og er normalt sproguafhængige. CORBA er et klassisk eksempel, selvom det nu er mindre almindeligt sammenlignet med alternativer som gRPC eller REST.
• Web API'erDisse eksponerer tjenester, der generelt er tilgængelige via HTTP/HTTPS, med data i JSON- eller XML-format. Dette inkluderer API'er til tjenester som f.eks. Google Maps, Twitter, PayPal eller stort set enhver moderne SaaS.

Derudover opretter mange organisationer Interne API'er så deres egne teams kan kommunikere mellem mikrotjenester, interne applikationer og databaser på en ordnet og kontrolleret måde.

Valg og kombination af frameworks, biblioteker og API'er i et projekt

I et rigtigt projekt vælger man sjældent kun ét af disse stykker. Normalt kombinere et framework, flere biblioteker og flere API'er ekstern eller intern til at bygge din applikation.

Du finder måske dette nyttigt vejledende regel:

• Hvis du bygger en komplet applikation fra bunden og ønsker at gøre det hurtigere og mere organiseret, Start med en ramme.
• Hvis du har brug for at løse specifikke problemer (datoer, PDF'er, diagrammer, maskinlæring osv.), søg efter specialiserede biblioteker som du kan integrere.
• Hvis din app skal kommunikere med andre systemer, udnytte API'er som disse systemer eksponerer (eller definer din egen API, så andre kan integrere med dig).

Forestil dig en webapplikation skrevet med Django som et framework. Indeni bruger du biblioteker som nusset o Pude Hvis du har brug for numeriske beregninger eller billedbehandling, vil du forbruge OpenWeather API at vise vejrudsigter, og dermed kan din egen applikation eksponere en REST Web API, så andre interne værktøjer i din virksomhed kan forespørge på dens data.

I sidste ende er nøglen at forstå, at De er ikke udskiftelige udtrykEt bibliotek er kode, et framework er struktur, og et API er den kontrakt, der binder delene sammen. At mestre disse tre niveauer giver dig mulighed for at bygge software, der er mere vedligeholdelsesvenlig, mere skalerbar og meget nemmere at integrere med resten af ​​den digitale verden.

At mestre forskellene og forholdet mellem biblioteker, frameworks og API'er er ikke kun et spørgsmål om teori eller fint ordforråd: det omsættes til træffe bedre tekniske beslutninger, undgå misforståelser i teamet og få mere ud af de værktøjer, du allerede bruger hver dag, uden at tænke for meget over det.