Medtem ko ste pili kavo, se je razvoj aplikacije Java spremenil -ponovno.
V svetu, ki ga poganjajo hitre spremembe in inovacije, je ironično, da se API-ji vračajo. Tako kot kodni ekvivalent newyorškega sistema podzemne železnice v dobi avtonomnih avtomobilov so tudi API-ji stara tehnologija- starodaven, vendar nepogrešljiv. Zanimivo je, kako je ta nevidna, vsakdanja IT arhitektura na novo zasnovana in uporabljena v trenutnih tehnoloških trendih.
Čeprav so API-ji povsod, so postali še posebej vidni v svoji oddaljeni inkarnaciji kot storitve RESTful, ki so hrbtenica uvajanja v oblaku. Storitve v oblaku so javni API-ji, za katere so značilne javno usmerjene končne točke in objavljene strukture. Tudi oblačne aplikacije so v trendu mikro storitve, ki so neodvisne, vendar povezane razmestitve. Vsi ti dejavniki povečujejo pomembnost API-jev.
V tej dvodelni vadnici boste izvedeli, kako postaviti API-je Java v središče procesa načrtovanja in razvoja, od zasnove do kodiranja. 1. del se začne s pregledom in vam predstavi OpenAPI, znan tudi kot Swagger. V 2. delu boste izvedeli, kako uporabljati definicije API-ja Swagger za razvoj aplikacije Spring Web MVC z vmesnikom Angular 2.
Kaj je Java API?
API-ji so tako običajni pri razvoju programske opreme, da se včasih domneva, da programerji preprosto vedo, kaj so. Namesto da se zanašamo na osmozo, si vzemimo minuto, da razpakiramo, kaj mislimo, ko govorimo o API-jih.
Na splošno lahko rečemo, da API-ji postavljajo in upravljajo meje med sistemi.Najprej, API pomeni "vmesnik za programiranje programov". Vloga API-ja je določiti, kako komponente programske opreme delujejo. Če poznate objektno usmerjeno programiranje, API-je v njihovi inkarnaciji poznate kot vmesnike in razrede, ki se uporabljajo za dostop do osnovnih značilnosti jezika, ali kot javni obraz knjižnic drugih proizvajalcev in zmogljivosti operacijskega sistema.
Na splošno lahko rečemo, da API-ji določajo in upravljajo meje med sistemi, kot je razvidno iz slike 1.
Matthew Tyson Kje nas torej pušča razvoj, ki ga vodi API?
Java API-ji za računalništvo v oblaku, mikro storitve in REST
Programiranje z API-ji prihaja v ospredje s sodobnim spletnim API-jem: a omrežno izpostavljeni API (NEA), kjer je meja med sistemi "prek žice". Te meje so že osrednjega pomena za spletne aplikacije, ki so skupna stična točka med vmesnimi odjemalci in zalednimi strežniki. Revolucija v oblaku je eksponentno povečala pomen Java API-jev.
Vsaka programska dejavnost, ki zahteva porabo storitev v oblaku (ki so v bistvu javni API-ji) in razgradnjo sistemov v manjše, neodvisne, a povezane razmestitve (znane tudi kot mikro storitve), je v veliki meri odvisna od API-jev. Omrežno izpostavljeni API-ji so preprosto bolj univerzalni, enostavnejši za pridobivanje ter lažje spreminjanje in razširjanje kot tradicionalni API-ji. Trenutni arhitekturni trend je izkoristiti te značilnosti.
Mikroservice in javni API-ji so nastali iz korenin storitveno usmerjene arhitekture (SOA) in programske opreme kot storitve (SaaS). Čeprav je SOA trend že vrsto let, je splošno sprejemanje ovirano zaradi zapletenosti in režijskih stroškov SOA. Industrija se je odločila za API-je RESTful kot dejanski standard, ki zagotavlja ravno dovolj strukture in konvencije z večjo realno prilagodljivostjo. Z REST kot ozadjem lahko ustvarimo formalne definicije API, ki ohranjajo človeško berljivost. Razvijalci ustvarjajo orodja okoli teh opredelitev.
Na splošno je REST dogovor za preslikavo virov na poti HTTP in z njimi povezana dejanja. Verjetno ste jih videli kot HTTP GET in POST metodi. Ključno je, da kot standard uporabimo sam HTTP, poleg tega pa za predvidljivost položimo običajne preslikave.
Uporaba Java API-jev pri oblikovanju
Lahko vidite pomembnost API-jev, toda kako bi jih uporabili v svoj prid?
Uporaba definicij Java API za usmerjanje procesa načrtovanja in razvoja je učinkovit način za strukturiranje vašega razmišljanja o IT sistemih. Z uporabo definicij Java API od samega začetka življenjskega cikla razvoja programske opreme (zbiranje konceptov in zahtev) boste ustvarili dragocen tehnični artefakt, ki je uporaben tako do uvedbe kot tudi za tekoče vzdrževanje.
Poglejmo, kako definicije Java API premoščajo konceptualno in izvedbeno fazo razvoja.
Opisni in predpisni API-ji
Koristno je razlikovati med opisnimi in predpisljivimi API-ji. A opisni API opisuje način, kako koda dejansko deluje, medtem ko a predpisani API opisuje, kako koda bi morali funkcijo.
Oba sloga sta uporabna in oba sta močno izboljšana z uporabo strukturirane standardne oblike za definicijo API-ja. Praviloma je uporaba API-ja za pogon ustvarjanja kode predpisana uporaba, medtem ko je uporaba kode za izhod definicije Java API opisna uporaba.
Zbiranje zahtev z Java API-ji
V spektru konceptualnih do izvedbe je zbiranje zahtev na konceptni strani. Toda tudi v konceptualni fazi razvoja aplikacije lahko začnemo razmišljati v smislu API-jev.
Recimo, da se vaš zasnovan sistem ukvarja z gorskimi kolesi - konstrukcijo, deli itd. Kot objektno usmerjen razvijalec bi začeli s pogovorom z zainteresiranimi stranmi o zahtevah. Precej hitro po tem bi razmišljali o povzetku BikePart razred.
Nato bi razmislili o spletni aplikaciji, ki bi upravljala različne predmete delov koles. Kmalu bi prišli do skupnih zahtev za upravljanje teh delov koles. Tu je posnetek faza zahtev dokumentacije za aplikacijo kolesarskih delov:
- Aplikacija mora biti sposobna ustvariti vrsto kolesarskega dela (menjalnik, zavora itd.).
- Pooblaščeni uporabnik mora biti sposoben seznam, ustvarjanje in aktiviranje vrste dela.
- Nepooblaščen uporabnik mora imeti možnost, da navede aktivne vrste delov in si ogleda sistem posameznih primerkov tipa dela v sistemu.
Že vidite obrise storitev, ki se oblikujejo. Z mislijo na morebitne API-je lahko začnete skicirati te storitve. Kot primer je tukaj delni seznam storitev RESTful CRUD za vrste kolesarskih delov:
- Ustvari vrsto kolesarskega dela:
PUT / delni tip / - Posodobi vrsto kolesarskega dela:
POST / delni tip / - Seznam delov seznama:
GET / del-tip / - Pridobite podrobnosti o vrsti dela:
GET / del-tip /: id
Opazite, kako storitve CRUD začnejo namigovati na obliko različnih meja storitev. Če gradite v slogu mikro storitev, lahko že vidite tri mikro storitve, ki izhajajo iz zasnove:
- Storitev kolesarskega dela
- Storitev delnega kolesa
- Storitev overjanja / avtorizacije
Ker API-je mislim kot meje povezanih entitet, Menim, da so mikrostoritve s tega seznama API površine. Skupaj ponujajo širok pogled na arhitekturo aplikacije. Podrobnosti o samih storitvah so opisane tudi na način, ki ga boste uporabili za tehnično specifikacijo, ki je naslednja faza življenjskega cikla razvoja programske opreme.
Tehnična specifikacija z Java API-ji
Če ste fokus API vključili kot del zbiranja zahtev, potem že imate dober okvir za tehnične specifikacije. Naslednja faza je izbira tehnološkega sklada, ki ga boste uporabili za izvedbo specifikacije.
S tako veliko osredotočenostjo na izdelavo RESTful API-jev imajo razvijalci zadrego bogastva, ko gre za implementacijo. Ne glede na izbrani niz, bo na tej stopnji še bolj podrobno določil API, da boste bolje razumeli arhitekturne potrebe aplikacije. Možnosti lahko vključujejo VM (navidezni stroj) za gostovanje aplikacije, bazo podatkov, ki lahko upravlja obseg in vrsto podatkov, ki jih strežete, in oblačno platformo v primeru uvedbe IaaS ali PaaS.
API lahko uporabite za usmerjanje navzdol proti shemam (ali strukturam dokumentov v NoSQL) ali navzgor proti elementom uporabniškega vmesnika. Ko boste razvijali specifikacijo API, boste verjetno opazili medsebojno delovanje teh pomislekov. To je vse dobro in del procesa. API postane osrednje, živo mesto za zajem teh sprememb.
Upoštevati morate še eno skrb, katere javne API-je bo izpostavil vaš sistem. Tem še dodatno razmislite in poskrbite. Javni API-ji poleg pomoči pri razvojnih prizadevanjih služijo kot objavljena pogodba, ki jo zunanji sistemi uporabljajo za povezavo z vašo.
Javni API-ji v oblaku
Na splošno API-ji opredeljujejo pogodbo programskega sistema in zagotavljajo znan in stabilen vmesnik, na podlagi katerega lahko programirajo druge sisteme. Natančneje, javni oblak API je javno naročilo z drugimi organizacijami in programerji, ki gradijo sisteme. Primeri so API-ji GitHub in Facebook.
Dokumentiranje Java API
Na tej stopnji boste želeli začeti zajemati svoje API-je v formalni sintaksi. V tabeli 1 sem naštel nekaj pomembnih standardov API.
Primerjava formatov API
| Ime | Povzetek | Zvezde na GitHubu | URL |
|---|---|---|---|
| OpenAPI | Podprta API-ja JSON in YML API, ki izhaja iz projekta Swagger, vključuje različna orodja v ekosistemu Swagger. | ~6,500 | //github.com/OAI/OpenAPI-Specification |
| RAML | Specifikacije na osnovi YML, ki jih podpira predvsem MuleSoft | ~3,000 | //github.com/raml-org/raml-spec |
| API BluePrint | Jezik za oblikovanje API-jev, ki uporablja skladnjo, podobno MarkDownu | ~5,500 | //github.com/apiaryio/api-blueprint/ |
Skoraj vsaka oblika, ki jo izberete za dokumentiranje API-ja, mora biti v redu. Samo poiščite obliko, ki je strukturirana, vsebuje formalne specifikacije in dobro orodje ter kaže, da se bo dolgoročno aktivno vzdrževala. Tako RAML kot OpenAPI ustrezata temu računu. Drug lep projekt je API Blueprint, ki uporablja sintakso označevanja. Za primere v tem članku bomo uporabili OpenAPI in Swagger.
OpenAPI in Swagger
OpenAPI je oblika JSON za opisovanje API-jev, ki temeljijo na REST. Swagger se je začel kot OpenAPI, vendar se je razvil v nabor orodij okoli formata OpenAPI. Obe tehnologiji se dobro dopolnjujeta.
Predstavljamo OpenAPI
OpenAPI je trenutno najpogostejša izbira za ustvarjanje definicij RESTful. Prepričljiva alternativa je RAML (RESTful API Markup Language), ki temelji na YAML. Osebno se mi zdi orodje v Swaggerju (zlasti vizualnem oblikovalcu) bolj uglajeno in brez napak kot v RAML-u.
OpenAPI uporablja sintakso JSON, ki jo pozna večina razvijalcev. Če raje ne obremenjujete oči pri razčlenjevanju JSON-a, obstajajo uporabniški vmesniki, ki olajšajo delo z njim. Drugi del predstavlja uporabniške vmesnike za definicije RESTful.
Seznam 1 je vzorec sintakse JAPON OpenAPI.
Seznam 1. Definicija OpenAPI za preprost BikePart
"paths": {"/ part-type": {"get": {"description": "Pridobi vse vrste delov, ki so na voljo v sistemu", "operationId": "getPartTypes", "produce": ["application / json "]," response ": {" 200 ": {" description ":" Pridobi BikeParts "," schema ": {" type ":" array "," items ": {" $ ref ":" # / definitions / BikePart "}}}}}}} Ta definicija je tako jedrnata, da je praktično špartanska, kar je za zdaj v redu. Obstaja dovolj prostora za povečanje podrobnosti in zapletenosti definicije API-ja naprej. V kratkem vam pokažem podrobnejšo ponovitev te definicije.
Kodiranje iz Java API
Zbiranje zahtev je končano in osnovna aplikacija je natančno določena, kar pomeni, da ste pripravljeni na zabaven del - kodiranje! Formalna definicija Java API vam daje nekaj posebnih prednosti. Kot prvo veste, katere končne točke morajo razviti zaledni in čelni razvijalci oziroma kodirati. Tudi če ste ekipa v enem, boste hitro začeli uporabljati API-pristop, ko začnete s kodiranjem.
Ko izdelujete aplikacijo, boste videli tudi vrednost uporabe API-jev za zajemanje povratnih pogajanj med razvojem in podjetjem. Uporaba orodij API bo pospešila tako uporabo kot dokumentiranje sprememb kode.
Podrobnejše specifikacije in dejansko kodiranje bodo morda zahtevale več podrobnosti kot kratka definicija iz seznama 1. Poleg tega bi lahko večji in bolj zapleteni sistemi zaslužili zmogljivosti, ki se bodo spreminjale, na primer sklicevanja na dokumente. Seznam 2 prikazuje bolj podroben primer API-ja BikePart.
Seznam 2. Dodajanje podrobnosti v definicijo BikePart API
"paths": {"/ part-type": {"get": {"description": "Pridobi vse vrste delov, ki so na voljo v sistemu", "operationId": "getPartTypes", "produce": ["application / json "]," parametri ": [{" name ":" limit "," in ":" query "," description ":" največje število rezultatov, ki jih je treba vrniti "," required ": false," type ": "integer", "format": "int32"}], "response": {"200": {"description": "seznam delnih tipov", "schema": {"type": "array", "items ": {" $ ref ":" # / definitions / PartType "}}}," default ": {" description ":" nepričakovana napaka "," schema ": {" $ ref ":" # / definitions / Error " }}}} 
