Kamēr jūs gatavojāt kafiju, Java lietojumprogrammu izstrāde mainījās -atkal.
Pasaulē, kuru virza straujas pārmaiņas un jauninājumi, ir ironiski, ka API atgriežas. Tāpat kā kodēšanas ekvivalents Ņujorkas metro sistēmai autonomo automašīnu laikmetā, arī API ir vecā tehnika- senatnīgs, bet neaizstājams. Interesanti ir tas, kā šī neredzamā ikdienas IT arhitektūra tiek pārdomāta un izmantota pašreizējās tehnoloģiju tendencēs.
Kaut arī API ir visur, tie ir kļuvuši īpaši nozīmīgi to attālajā iemiesojumā kā RESTful pakalpojumi, kas ir mākoņa izvietošanas pamats. Mākoņpakalpojumi ir publiskās API, kam raksturīgi ar sabiedrību vērsti galapunkti un publicētās struktūras. Arī uz mākoni balstītas lietotnes virzās uz priekšu mikropakalpojumi, kas ir neatkarīgi, bet saistīti izvietojumi. Visi šie faktori palielina API svarīgumu.
Šajā divu daļu apmācībā jūs uzzināsiet, kā Java API ievietot dizaina un izstrādes procesa centrā, sākot no koncepcijas līdz kodēšanai. 1. daļa sākas ar pārskatu un iepazīstina jūs ar OpenAPI, kas pazīstams arī kā Swagger. 2. daļā jūs uzzināsiet, kā izmantot Swagger API definīcijas, lai izveidotu Spring Web MVC lietotni ar Angular 2 priekšgalu.
Kas ir Java API?
API programmatūras izstrādē ir tik izplatīta, ka dažreiz tiek pieņemts, ka programmētāji vienkārši zina, kas viņi ir. Tā vietā, lai paļautos uz osmozi, izmantosim minūti, lai izpakotu to, ko mēs domājam, runājot par API.
Kopumā mēs varam teikt, ka API nosaka un pārvalda robežas starp sistēmām.Pirmkārt, API nozīmē "lietojumprogrammu saskarne". API uzdevums ir norādīt, kā mijiedarbojas programmatūras komponenti. Ja esat iepazinies ar objektorientēto programmēšanu, jūs to API iemiesojumā pazīstat kā saskarnes un klases, kas tiek izmantotas, lai iegūtu piekļuvi valodas pamatfunkcijām, vai kā trešo pušu bibliotēku un OS iespēju publisko seju.
Kopumā mēs varam teikt, ka API nosaka un pārvalda robežas starp sistēmām, kā redzams 1. attēlā.
Metjū Taisons Tātad, kur tas mūs atstāj ar API virzītu attīstību?
Java API mākoņdatošanai, mikropakalpojumiem un REST
Programmēšana ar API nāk priekšplānā ar moderno tīmekļa API: a tīkla pakļauta API (NEA), kur robeža starp sistēmām ir "pāri vadam". Šīs robežas jau ir centrālas tīmekļa lietotnēs, kas ir kopīgs saskarsmes punkts starp priekšgala klientiem un aizmugures serveriem. Mākoņu revolūcija ir eksponenciāli palielinājusi Java API nozīmi.
Jebkura programmēšanas darbība, kas prasa mākoņpakalpojumu (kas būtībā ir publiskas API) patērēšanu un sistēmu dekonstruēšanu mazākās, neatkarīgās, bet saistītās izvietojumos (pazīstamas arī kā mikropakalpojumi), lielā mērā balstās uz API. Tīklam pakļautās API ir vienkārši universālākas, vieglāk iegūstamas un vieglāk modificējamas un paplašinātas nekā tradicionālās API. Pašreizējā arhitektūras tendence ir izmantot šīs iespējas.
Mikroservisi un publiskās saskarnes ir izveidotas no uz pakalpojumu orientētas arhitektūras (SOA) un programmatūras kā pakalpojuma (SaaS) saknēm. Lai gan SOA ir bijusi tendence daudzus gadus, plašu ieviešanu kavē SOA sarežģītība un pieskaitāmās izmaksas. Nozare ir apņēmusies RESTful API kā de facto standartu, nodrošinot pietiekami daudz struktūras un principu ar lielāku elastību reālajā pasaulē. Tā kā REST ir fons, mēs varam izveidot oficiālas API definīcijas, kas saglabā cilvēka lasāmību. Izstrādātāji izveido rīkus ap šīm definīcijām.
Kopumā REST ir konvencija resursu kartēšanai uz HTTP ceļiem un ar tiem saistītajām darbībām. Jūs, iespējams, redzējāt šīs kā HTTP GET un POST metodes. Galvenais ir izmantot pašu HTTP kā standartu, un, lai to varētu paredzēt, virs tā kārtojiet parastos kartējumus.
Java API izmantošana projektēšanā
Jūs varat redzēt API nozīmīgumu, bet kā jūs tos izmantotu savā labā?
Java API definīciju izmantošana projektēšanas un izstrādes procesa virzīšanai ir efektīvs veids, kā strukturēt domāšanu par IT sistēmām. Izmantojot Java API definīcijas programmatūras izstrādes dzīves cikla sākumā (koncepcijas un prasību apkopošana), jūs izveidosiet vērtīgu tehnisku artefaktu, kas ir noderīgs līdz izvietošanai, kā arī pastāvīgai uzturēšanai.
Apsvērsim, kā Java API definīcijas apvieno konceptuālos un ieviešanas attīstības posmus.
Aprakstošās un aprakstošās API
Ir lietderīgi nošķirt aprakstošās un aprakstošās API. A aprakstoša API apraksta kodu reālo darbību, turpretī a recepšu API apraksta, kā kods vajadzētu funkciju.
Abi šie stili ir noderīgi, un abi tiek ievērojami uzlaboti, izmantojot API strukturēšanai strukturētu standarta formātu. Pēc īkšķa noteikuma API izmantošana koda izveidē ir aprakstoša, savukārt koda izmantošana Java API definīcijas izvadei ir aprakstoša.
Prasību apkopošana ar Java API
No konceptuālā līdz īstenošanai spektrā prasību apkopošana ir ideāla puse. Bet pat lietotņu izstrādes konceptuālajā posmā mēs varam sākt domāt par API.
Pieņemsim, ka jūsu projektētā sistēma nodarbojas ar kalnu velosipēdiem - konstrukciju, detaļām utt. Kā objektorientēts izstrādātājs, vispirms runājiet ar ieinteresētajām personām par prasībām. Diezgan ātri pēc tam jūs domājat par abstraktu BikePart klasē.
Pēc tam jūs domājat, izmantojot tīmekļa lietojumprogrammu, kas pārvaldītu dažādus velosipēdu detaļu objektus. Drīz jūs sasniegtu kopīgas prasības, lai pārvaldītu šīs velosipēdu daļas. Lūk, momentuzņēmums prasību fāze velosipēdu detaļu lietotnes dokumentācija:
- Lietojumprogrammai jāspēj izveidot velosipēda daļas tips (pārnesumu pārslēdzējs, bremze utt.).
- Autorizētam lietotājam jāspēj uzskaitīt, izveidot un aktivizēt detaļu tipu.
- Neautorizētam lietotājam jāspēj uzskaitīt aktīvo daļu tipus un apskatīt sistēmas atsevišķu daļu tipa gadījumu gadījumus.
Jau tagad jūs varat redzēt, kā veidojas pakalpojumu aprises. Paturot prātā API, jūs varat sākt ieskicēt šos pakalpojumus. Piemēram, šeit ir daļējs RESTful CRUD pakalpojumu saraksts velosipēdu daļu tipiem:
- Izveidot velosipēda daļu:
PUT / daļas tips / - Atjaunināt velosipēda daļu:
POST / daļas tips / - Saraksta daļu veidi:
GET / daļas tips / - Iegūt detaļas detaļas:
GET / part-type /: id
Ievērojiet, kā CRUD pakalpojumi sāk dot mājienu par dažādu pakalpojumu robežu formu. Ja veidojat mikropakalpojumu stilā, jūs jau varat redzēt trīs dizaina mikropakalpojumus:
- Velosipēdu daļas serviss
- Velosipēdu daļas serviss
- Autentifikācijas / autorizācijas pakalpojums
Jo es domāju par API kā saistīto vienību robežas, Es uzskatu, ka mikropakalpojumi no šī saraksta ir API virsmas. Kopā tie piedāvā lietojumprogrammas arhitektūras skatu lielā attēlā. Sīkāka informācija par pašiem pakalpojumiem ir aprakstīta arī tādā veidā, kuru izmantosiet tehniskajā specifikācijā, kas ir nākamais programmatūras izstrādes dzīves cikla posms.
Tehniskā specifikācija ar Java API
Ja prasību apkopošanā esat iekļāvis API fokusu, jums jau ir labs ietvars tehniskajām specifikācijām. Nākamais posms ir tehnoloģiju kaudzes izvēle, kuru izmantosiet, lai ieviestu specifikāciju.
Ar tik lielu uzmanību pievēršot RESTful API izveidošanai, izstrādātājiem ir neērti bagātības, kad runa ir par ieviešanu. Neatkarīgi no izvēlētās kaudzes, API pilnveidošana šajā posmā palielinās jūsu izpratni par lietotnes arhitektūras vajadzībām. Iespējas var ietvert VM (virtuālo mašīnu) lietojumprogrammas mitināšanai, datu bāzi, kas spēj pārvaldīt jūsu apkalpoto datu apjomu un veidu, un mākoņa platformu IaaS vai PaaS izvietošanas gadījumā.
Varat izmantot API, lai virzītos "uz leju" virzienā uz shēmām (vai dokumentu struktūrām n NoSQL) vai "uz augšu" uz lietotāja saskarnes elementiem. Izstrādājot API specifikāciju, iespējams, pamanīsit šo problēmu mijiedarbību. Tas viss ir labi un ir daļa no procesa. API kļūst par centrālo dzīvesvietu šo izmaiņu fiksēšanai.
Vēl viena problēma, kas jāpatur prātā, ir tas, kuras publiskās API jūsu sistēma parādīs. Piešķiriet tām papildu uzmanību un rūpējieties. Līdztekus palīdzībai attīstības centienos publiskās API ir publicētais līgums, kuru ārējās sistēmas izmanto, lai mijiedarbotos ar jūsu.
Publiskās mākoņa API
Parasti API nosaka programmatūras sistēmas līgumu, nodrošinot zināmu un stabilu saskarni, pret kuru programmēt citas sistēmas. Konkrēti, publiskā mākoņa API ir publisks līgums ar citām organizācijām un programmētājiem, kas veido sistēmas. Piemēri ir GitHub un Facebook API.
Java API dokumentēšana
Šajā posmā jūs vēlaties sākt uztvert API oficiālajā sintaksē. 1. tabulā esmu uzskaitījis dažus ievērojamus API standartus.
API formātu salīdzināšana
| Nosaukums | Kopsavilkums | Zvaigznes vietnē GitHub | URL |
|---|---|---|---|
| OpenAPI | JSON un YML atbalstītais API standarts, kas cēlies no Swagger projekta, ietver dažādus rīkus Swagger ekosistēmā. | ~6,500 | //github.com/OAI/OpenAPI-Specification |
| RAML | YML balstīta spec, kuru galvenokārt atbalsta MuleSoft | ~3,000 | //github.com/raml-org/raml-spec |
| API BluePrint | API noformējuma valoda, izmantojot MarkDown līdzīgu sintaksi | ~5,500 | //github.com/apiaryio/api-blueprint/ |
Praktiski jebkuram formātam, kuru izvēlaties dokumentēt savu API, jābūt kārtībā. Vienkārši meklējiet strukturētu formātu, kuram ir oficiāla specifikācija un labs rīks, un izskatās, ka tas tiks aktīvi uzturēts ilgtermiņā. Gan RAML, gan OpenAPI atbilst šim rēķinam. Vēl viens veikls projekts ir API Blueprint, kurā tiek izmantota iezīmēšanas sintakse. Piemēri šajā rakstā mēs izmantosim OpenAPI un Swagger.
OpenAPI un Swagger
OpenAPI ir JSON formāts, lai aprakstītu uz REST balstītas API. Swagger sāka kā OpenAPI, bet ir pārtapis par rīku kopumu ap OpenAPI formātu. Abas tehnoloģijas labi papildina viena otru.
Iepazīstinām ar OpenAPI
Pašlaik OpenAPI ir visizplatītākā izvēle, lai izveidotu RESTful definīcijas. Pārliecinoša alternatīva ir RAML (RESTful API Markup Language), kuras pamatā ir YAML. Personīgi man Swagger (it īpaši vizuālā dizainera) instrumenti ir vairāk slīpēti un bez kļūdām nekā RAML.
OpenAPI izmanto JSON sintaksi, kas ir pazīstama lielākajai daļai izstrādātāju. Ja nevēlaties apgrūtināt savas acis, analizējot JSON, ir lietotāja interfeisi, kas atvieglo darbu ar to. 2. daļa ievieš lietotāja saskarnes RESTful definīcijām.
1. saraksts ir OpenAPI JSON sintakses paraugs.
Saraksts 1. OpenAPI definīcija vienkāršai BikePart
"paths": {"/ part-type": {"get": {"description": "Iegūst visus sistēmā pieejamos daļu tipus", "operationId": "getPartTypes", "produkcija": ["lietojumprogramma / json "]," responses ": {" 200 ": {" description ":" Gets the BikeParts "," schema ": {" type ":" array "," items ": {" $ ref ":" # / definīcijas / BikePart "}}}}}}} Šī definīcija ir tik kodolīga, ka praktiski tā ir spartiete, kas pagaidām ir kārtībā. Turpmāk ir daudz iespēju palielināt API definīcijas detalizētību un sarežģītību. Drīz es jums parādīšu detalizētāku šīs definīcijas atkārtojumu.
Kodēšana no Java API
Prasību apkopošana ir pabeigta, un pamata lietotne ir specded out, kas nozīmē, ka jūs esat gatavs jautrajai daļai --- kodēšana! Oficiāla Java API definīcija sniedz dažas atšķirīgas priekšrocības. Pirmkārt, jūs zināt, kādi galapunkti back-end un front-end izstrādātājiem ir attiecīgi jāizveido un jākodē. Pat ja esat viena komanda, sākat kodēt, jūs ātri redzēsiet API virzītas pieejas vērtību.
Izstrādājot lietojumprogrammu, jūs redzēsiet arī vērtību, kāda ir API izmantošanai, lai piesaistītu turp un atpakaļ sarunas starp attīstību un uzņēmējdarbību. API rīku izmantošana paātrinās gan kodu izmaiņu piemērošanu, gan to dokumentēšanu.
Lai iegūtu detalizētākas specifikācijas un faktisko kodēšanu, var būt nepieciešama detalizētāka informācija par 1. saraksta precīzo definīciju. Turklāt lielākas un sarežģītākas sistēmas varētu nopelnīt iespējas, kuras tiks mērogotas, piemēram, dokumentu atsauces. 2. saraksts parāda pilnīgāku BikePart API piemēru.
Saraksts 2. Detalizētas informācijas pievienošana BikePart API definīcijai
"paths": {"/ part-type": {"get": {"description": "Iegūst visus sistēmā pieejamos daļu tipus", "operationId": "getPartTypes", "produc": ["lietojumprogramma / json "]," parametri ": [{" nosaukums ":" ierobežojums "," iekš ":" vaicājums "," apraksts ":" maksimālais atgriezamo rezultātu skaits "," obligāti ": nepatiesa," tips ": "integer", "format": "int32"}], "atbildes": {"200": {"description": "daļas tipa saraksts", "shēma": {"type": "masīvs", "vienumi" ": {" $ ref ":" # / definitions / PartType "}}}," default ": {" description ":" neparedzēta kļūda "," schema ": {" $ ref ":" # / definitions / Error " }}}} 
