Skip to content

Latest commit

 

History

History
436 lines (305 loc) · 14.1 KB

06.1.ws.md

File metadata and controls

436 lines (305 loc) · 14.1 KB
Raw

Fyrirlestur 6.1 — Vefþjónustur

Vefforritun 2 — HBV403G

Ólafur Sverrir Kjartansson, [email protected]

Vefþjónustur

  • Margt fellur undir hugtakið vefþjónusta
  • Í grunninn einhver samskipti milli tölva yfir net
  • Verið til í einhverri mynd síðan farið var að tengja saman tölvur
  • W3C skilgreining:
    • "A Web service is a software system designed to support interoperable machine-to-machine interaction over a network"
    • Vefþjónusta er hugbúnaðarkerfi hannað til að eiga samvirk samskipti, vél-í-vél yfir net

Samvirkni – interoperability

  • Samvirkni gengur út á að láta kerfi virka saman
  • Syntactic interoperability – málskipunarsamvirkni
    • Við getum talað saman og skipst á gögnum
  • Semantic interoperability – merkingarbærsamvirkni
    • Við vitum merkinguna í samskiptum okkar—getum túlkað

Áður fyrr...

SOA – Service Oriented Architecture

  • Hönnunar og arkitektúra mynstur sem byggir á því að hugbúnaður veiti virkni sem þjónustu til annars hugbúnaðar
  • Til þess þurfum við
    • Lýsingu á þjónustu
    • Lýsingu á samskiptum

WSDL

  • Web Service Description Language, lýsing á þjónustu sem byggir á XML og er stöðluð af W3C
  • Skilgreinir t.d.:
    • Týpur, einfaldar og flóknar
    • Aðgerðir og inntak/úttak þeirra
    • Endapunkt, hvert á að kalla á þjónustuna
  • Langoftast eru notuð tól sem búa til kóða útfrá WSDL

SOAP

  • Protocol—samskiptareglur—til að skiptast á skipulegum gögnum í útfærslum á vefþjónustum
  • Notar XML fyrir form og oftast HTTP fyrir gagnasendingar – POST-um gögnum á endapunkt
  • Stóð upprunalega fyrir Simple Object Access Protocol en því var hætt þegar W3C tók yfir stöðlun
  • SOAP skilaboð eru sett inn í umslag sem inniheldur haus (valkvæmt) og meginmál
<?xml version="1.0"?>
<soap:Envelope
  xmlns:soap="http://www.w3.org/2003/05/soap-envelope/"
>
  <soap:Body>
    <m:message>
      <m:string>Hello world</m:string>
    </m:message>
  </soap:Body>
</soap:Envelope>

WCF

Microservices

  • Nýleg túlkun á SOA til að útfæra dreifð kerfi
  • Einblínir á að skipta forriti upp í lauslega tengda (loosely coupled) hluta
  • Góð hugmynd en krefst mikils aga og skipulags í útfærslu

HTTP aðferðir

  • GET – biður um útgáfu af tilgreindri auðlind, lang mest notaða aðferðin
  • HEAD – einsog GET, nema vill aðeins fá hausa skilgreinda fyrir auðlind
  • POST – Biður server um að taka við einingu í request sem nýrri einingu, skilgreinda með URI. T.d. nýtt svar við umræðuþræði eða ný gögn í gagnagrunni
  • PUT – biður um að eining í request sé geymd undir URI, ef önnur er til nú þegar skal uppfæra hana
  • DELETE – biður um að það sem geymt er á URI sé eytt
  • PATCH – uppfærir aðeins þá hluta einingar sem sendir eru
  • TRACE – Skilar request til baka, debug
  • OPTIONS – Skilar til baka hvaða aðferðir þjónn styður

Öryggi aðgerða

  • Ákveðnar aðgerðir (t.d. GET og HEAD) eru skilgreindar sem öruggar að því leiti að köll í þær fyrir auðlind á ekki að breyta neinni stöðu
  • Aðrar aðgerðir (t.d. POST og PUT) eru það ekki, þær munu að öllum líkindum breyta stöðu á vefþjón

Idempotency

  • PUT og DELETE eru aðgerðir sem eru idempotent, þ.e.a.s. að kalla í þær mörgum sinnum með sömu skilyrðum hefur sömu áhrif og að kalla einu sinni
  • POST og PATCH eru ekki idempotent þar sem hvert kall getur bætt við nýrri einingu eða breytt hluta einingar
  • GET og HEAD eru einnig idempotent þar sem HTTP er stöðulaust

Stöðukóðar — status codes

Þegar vefþjónn svarar með response gefur hann upp stöðukóða, sem tölu og lesanlegan texta

  • 1xx – Til upplýsinga
  • 2xx – Gekk, success
  • 3xx – Áframsending, redirection
  • 4xx – Villa hjá client
  • 5xx – Villa hjá server

200 kóðar

  • 200 OK – Staðlaða svarið, m.v. aðgerð gekk það sem beðið var um upp
  • 201 Created – Beiðni hefur verið uppfyllt og ný eining varð til
  • 202 Accepted – Beiðni móttekin en aðgerð hefur ekki verið uppfyllt
  • 204 No Content – Beiðni hefur verið uppfyllt en engu er svarað, t.d. vegna þess að einingu var eytt

300 kóðar

  • 301 Moved Permanently – Þessi og allar beiðnir í framtíði eiga að fara á nýtt URI (gefið í Location haus)
  • 304 Not Modified – Ekkert hefur breyst síðan í fyrri beiðni, m.v. If-Modified-Since eða If-None-Match hausa

400 kóðar

  • 400 Bad Request – Server getur ekki tekið við beiðni vegna villu hjá client, t.d. eru gögn ekki gild
  • 401 Unauthorized – Auðkenningar er krafist til að geta svarað beiðni
  • 403 Forbidden – Beiðni gild en server skilar ekki svari, t.d. er auðkenning ekki næg til að fá aðgang
  • 404 Not Found – Ekkert fannst á URI
  • 451 Unavailable For Legal Reasons

500 kóðar

  • 500 Internal Server Error – Server villa kom upp
  • 501 Not Implemented – Server skildi svar en kann (ekki ennþá) að svara
  • 503 Service Unavailable – Server getur ekki svarað, t.d. vegna anna

REST

  • Representational State Transfer, skilgreint í doktorsritgerð Roy Fielding frá árinu 2000
  • REST er arkitektúrsstíll sem hunsar útfærslu og samskipti en einblínir á hlutverk eininga, samskipti þeirra á milli og takmarkanir þar á
  • Skilgreinir sex takmarkanir á arkitektúr

REST takmarkanir

  • Client-server – samræmt viðmót aðskilur client og server
  • Stöðulaust – engin staða er geymd á milli beiðna
  • Cacheable – client getur geymt afrit af svari, svör verða því að skilgreina hvort það megi eða ekki
  • Lagskipt kerfi – client þarf ekki að vita hvort hann sé tengdur enda server eða hvort hann tengist einhverjum millilið
  • Kóði eftir þörfum (ekki krafist) – server getur sent kóða til client til að auka virkni hans
  • Samræmt viðmót – Grunnur að hönnun á REST þjónustu, einfaldur og aðskildur arkítektúr þ.a. client og server geta vaxið óháð hvor öðrum

Samræmt viðmót

  • Auðkennum auðlindir – biðjum um auðlind og fáum hana ekki sjálfa heldur framsetningu á henni
    • Biðjum um notanda og fáum einhverja framsetningu, t.d. sem JSON eða XML þó að vefþjónn noti þær ekki sjálfur til að geyma notanda
  • Sjálf-lýsandi skilaboð, við vitum alltaf nóg til að geta unnið með skilaboðin
  • Vinnum með auðlindir gegnum framsetningu – client sem þekkir framsetningu á auðlind veit nóg til að geta breytt henni
    • Framsettar upplýsingar um notanda eru nægar til að við getum breytt notanda
  • HATEOS

HATEOAS

  • Hypermedia As The Engine Of Application State
  • Client þarf engar frekari upplýsingar en þær sem hann fær í byrjun
    • Á skjön við t.d. WSDL þar sem við vitum allt í byrjun
  • Notar hypermedia til að komast áfram – fáum tengla til að fá frekari upplýsingar og breyta stöðum
  • Hypertext Application Language (HAL) staðlar hvernig þessum upplýsingum er komið til skila
{
  "_links": {
    "self": {
      "href": "http://example.com/api/book/hal-cookbook"
    },
    "next": {
      "href": "http://example.com/api/book/hal-case-study"
    }
  },
  "_embedded": {
    "author": {
      "id": "foo",
      "name": "Foo Bar"
    }
  },
}

REST & HTTP

  • Vefurinn er stærsta útfærsla á REST arkitektúr
    • Fielding einn af aðalhöfundum HTTP
  • Notum:
    • URI fyrir auðlindirnar okkar – nafnorðin
    • Content types fyrir framsetningu á auðlindum
    • HTTP aðgerðir til að tilgreina hvað við gerum – sagnirnar
  • HTTP skilgreinir caching, auðkenningu, content negotiation...

REST í raunveruleikanum

  • Þar sem REST skilgreinir ekki útfærslu er hægt að nota margt
    • Í fyrstu notuðu flestar REST vefþjónustur XML
    • Núna er JSON lang mest notað, bæði til að taka við gögnum og senda þau til baka
  • Margar vefþjónustur í dag útfærðar sem REST eða RESTful, þó þær uppfylli ekki öll skilyrði

Restful

  • RESTful: notum JSON, HTTP aðgerðir og stöðu kóða en látum annað liggja milli hluta
    • Kórrétt REST er flókið
  • (Ætlaður) einfaldleikinn er heillandi, sérstaklega í byrjun þegar fólk var þreytt á stórum og miklum XML skjölum
  • Gerum okkar besta til að útbúa góðar vefþjónustur sem er þægilegt að nota

Gallar við REST

  • Skilgreiningar á REST milli fólks er mismunandi—REST vs RESTful
  • Lítið af stöðluðum tólum sem hægt er að nýta
  • Takmarkanir á HTTP: stöðu kóðar og aðgerðir ná ekki yfir allt sem við viljum gera
  • Þurfum oft að gera mörg köll til að fá öll þau gögn sem okkur vantar
    • Eitt fyrir grein, annað fyrir höfund, enn annað fyrir flokk o.s.fr.
  • Í hverju kalli fáum við oft of mikið af upplýsingum

REST tól

  • Postman - GUI tól til að gera HTTP fyrirspurnir
  • cURL – CLI tól til að gera HTTP fyrirspurnir
  • Request - Library til að gera HTTP fyrirspurnir með node.js
  • JSON Formatter – Extension fyrir Chrome sem birtir JSON lesanlega

REST og express

  • Express getur auðveldlega sent frá sér JSON
    • res.json({ data: 'Einhver JS hlutur' });
  • Express kemur með JSON body parser middleware
    • app.use(express.json());
  • Fyrir skráa upload þurfum við samt ennþá middleware sem styður multipart

GET

  • Sækir allar færslur eða staka, fylki eða object
  • Ef færsla finnst, skilum 200 OK
  • Ef færsla finnst ekki, skilum 404 Not Found

POST

  • Býr til nýja færslu útfrá gefnu JSON
  • Ef færsla er lögleg, skilum 201 Created, stundum með færslu
  • Ef færsla er ekki lögleg (t.d. gögn eru ekki gild), skilum 400 Bad Request
  • Þurfum að passa upp á JSON villur frá notanda

Express og JSON villur

  • Ef notandi sendir JSON þarf að túlka það
    • Villur í JSON munu kasta keyrslu villu og án þess að bregðast við því myndum við senda 500 Internal Server Error þegar villan liggur hjá notanda
  • Getum bætt við athugun í villumeðhöndlun sem lætur vita
if (err instanceof SyntaxError &&
    err.status === 400 && 'body' in err) {
  return res
    .status(400)
    .json({ error: 'Invalid json' });
}

PUT

  • Uppfærir færslu að öllu leiti með gefnu JSON
  • Ef færsla finnst ekki, skilum 404 Not Found
  • Ef færsla er lögleg, skilum 200 OK, stundum með færslu
  • Ef færsla er ekki lögleg (t.d. gögn eru ekki gild), skilum 400 Bad Request

DELETE

  • Eyðir færslu
  • Ef færsla finnst ekki, skilum 404 Not Found
  • Annars skilum við 204 No Content með tóma JSON

GraphQL

  • Tilraun til að „laga“ það sem er að REST
    • Þróað og stutt af Facebook
  • Spec sem skilgreinir týpu kerfi og fyrirspurnarmál
  • Staðlaðar útfærslur og tól í mörgum málum
type Project {
  name: String
  tagline: String
  contributors: [User]
}
{
  project(name: "GraphQL") {
    tagline
  }
}
{
  "project": {
    "tagline": "A query language for APIs"
  }
}

Hönnun á vefjþónustum

  • Töluvert ólíkt því að hanna vefi með útliti
  • Neytendur okkar eru aðrir forritarar og þeirra forrit
    • Mun minna rými til að túlka eitthvað einsog villu á vef
    • Getum sparað öðrum ótrúlega mikinn tíma með því að vanda okkur
  • Þurfum að hugsa vel um samræmi
    • Samræmi á heitum (ekki username, userName og user-name)
    • Samræmi á URI (ekki /get-users, /products og /cats)
    • Samræmi á villuskilaboðum
  • Hugsum heildstætt, hvað gerist í hverju tilfelli?
    • Hvað ef beðið er um eitthvað sem er ekki til
    • Hvað ef villa kemur upp
    • o.s.fr.
  • Oft gott að aðskilja virknina okkar frá vefþjónustulaginu
    • Vefþjónustan kemur sem „þunnt lag“ ofan á virkni

Nánar