Schnittstellenarchitektur in Zeiten sich wandelnder Frontend-Technologien

Größe: px

Ab Seite anzeigen:

Download "Schnittstellenarchitektur in Zeiten sich wandelnder Frontend-Technologien"

Fritz Ackermann
vor 5 Jahren
Abrufe

1 Schnittstellenarchitektur in Zeiten sich wandelnder Frontend-Technologien Version: 1.0 Orientation in Objects GmbH Weinheimer Str Mannheim

2 Ihr Sprecher Thorsten Maier Trainer, Berater, Orientation in Objects GmbH Schnittstellenarchitektur in Zeiten sich wandelnder Frontend-Technologien 2

3 Frontend Backend 3

4 Wer ist alles hier? 4

5 Ich würde immer einen faulen Menschen wählen, um einen schwierigen Job zu erledigen. Er wird definitiv einen einfachen Weg finden. Bill Gates 5

6 Software Entwicklung Schwieriger Job Fauler Entwickler 6

7 Coole Software Zufriedene Kunden Don t repeat yourself Einfacher ist besser Keine Doku Wenig Technologien Fauler Entwickler 7

8 JAX 2018 geht zu Ende Was waren die Trends? 8

9 24x 15x Microservices immer noch 7x 11x Cloud ist nicht mehr neu 4x 10x APIs mehr denn je 9

10 Frontend API? Backend 10

lastname}"></span> </body> </html> @Controller public class PersonApplication { API?

11 <!DOCTYPE html> <html> <head> <title>person</title> </head> <body> </body> public class PersonApplication { API? public ModelAndView getperson() { return new ModelAndView("view", "person", new Person("Thorsten", "Maier")); } 11

12 Aus was besteht ein API? Datenstrukturen + Operationen 12

13 Architekten Ausbildung PRAXIS 13

14 1. Sich vorher auf Angular festlegen 2. Architektur Workshop ohne Anforderungen 3. Bei Angular bleiben 14

15 {{person.firstname}} {{person.lastname}} this.httpclient.get(' Person) => { this.person = person; public class PersonApplication { public Person getperson() { return new Person("Thorsten", "Maier"); } 15

16 {{person.firstname}} {{person.lastname}} this.httpclient.get(' Person) => { this.person = person; }); public class PersonApplication { public Person getperson() { return new Person("Thorsten", "Maier"); } 16

17 {{person.firstname}} {{person.lastname}} this.httpclient.get(' Person) => { this.person = person; }); public class PersonApplication { public Person getperson() { return new Person("Thorsten", "Maier"); } 17

18 {{person.firstname}} {{person.lastname}} this.httpclient.get(' Person) => { this.person = person; public class PersonApplication { Operation API! Datenstruktur public Person getperson() { return new Person("Thorsten", "Maier"); } 18

19 Na und??? 19

20 API verspricht Wiederverwendung 20

21 Die UI Technologie ändert sich alle paar Jahre Dann bauen wir das Backend so, dass wir es behalten können. Wir brauchen eine API. 21

22 Wiederverwendung ist 3x teurer Gründe: Test, Dokumentation, Abstraktion, lohnt sich erst ab dem 3. Mal 22

23 Was ist denn daran teurer? Wir machen einfach ein REST-API. Geht doch schnell. 23

24 Alles ist eine Ressource Firstname Lastname Employer Hobbies Dieter Develop OIO Coding, Biking 24

25 Jede Ressource hat eine URI 25

26 Ressourcen können mehrere Repräsentationen besitzen { } "firstname": "Dieter", "lastname": "Devekop", "employer": "OIO", "hobbies": ["Coding", "Biking"] <html> <head> <title>dieter s Homepage</title> </head> <body> <h1>my name is Dieter, welcome to my personal Homepage</h1> </body> </html> 26

27 Operationen in REST Ressource POST (create) GET (read) PUT (update) DELETE (delete) /person Person anlegen Alle Personen abrufen Alle Personen ändern Alle Personen löschen /person/4711 error Person 4711 abrufen Person 4711 ändern Person 4711 löschen 27

28 28

29 REST fehlt ein Standard 29

30 REST ist technisch new RestTemplate().getForObject( " Person.class, 1); Operation 30

31 Was immer alle vergessen HATEOAS Hypermedia as the engine of Application state 31

32 HATEOAS mit JSON { } "_links" : { "next" : { "href" : " "templated" : true } }, "_embedded" : {... data... }, "page" : { "size" : 5, "totalelements" : 50, "totalpages" : 10, "number" : 0 } 32

33 Niemand nutzt Hypermedia I am getting frustrated by the number of people calling any HTTP-based interface a REST API. Today s example is the SocialSite REST API. That is RPC. It screams RPC. [ ] What needs to be done to make the REST architectural style clear on the notion that hypertext is a constraint? In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period. Is there some broken manual somewhere that needs to be fixed? Roy T. Fielding, 2008, 33

34 Na gut, dann machen wir halt Hypermedia Links. Aber sonst ist doch alles klar! 34

35 REST ist datengetrieben stornierebestellung(74) // kein REST! DELETE /bestellung/74 // fachlich falsch? PATCH /bestellung/74 { "status": "storniert" } PUT /bestellung/74/storno 35

36 Aber Moment, es gibt doch 36

37 Datenstruktur mit JSON Schema definitions: Person: type: "object" properties: firstname: type: "string" lastname: type: "string" 37

38 Operation paths: /person: get: summary: "Get a list of all persons" operationid: "getperson" consumes: - "application/json" produces: - "application/json" responses: 200: description: "List of persons as JSON" schema: $ref: '#/definitions/person' 38

39 39

40 40

41 41

42 Generierung Generierung Swagger API Beschreibung Generierung Generierung API Test Zugriff API Implementierung Zugriff API Client 42

43 = "person", description = "the person API") public interface PersonApi { = "Get a person", nickname = "getperson", notes = "", response = Person.class, tags = = = 200, message = "Persons as JSON", response = Person.class) = "/person", produces = { "application/json" }, consumes = { "application/json" }, method = RequestMethod.GET) ResponseEntity<Person> getperson(); 43

44 API Generierung spart etwas Arbeit Vorlieben können nicht berücksichtigt werden Paketnamen Klassennamen Aufteilung der REST Controller 44

45 Was passiert bei einer Änderung? Swagger API Beschreibung API Test API Implementierung API Client 45

46 Was tun wir hier gerade? Wir bauen ein kundenorientiertes API Für einen Kunden: unsere eigene UI 46

47 Wozu benötige ich ein API? Wettbewerbsvorteil da andere in die Lage versetzt werden, zusätzliche Software für dieses System zu erstellen. Wiederverwendung 47

48 Richtige APIs sind richtig teuer Bisher Faktor 3 für Wiederverwendung 48

49 Verfügbarkeit? Laufzeitverhalten? Verhalten bei Last? Fehlerbehandlung? Eingabeparameter (Wertebereiche, nullable?, ) Ausgabeparameter? Vorbedingungen? Verständliche Dokumentation Eine API sollte minimal sein Synchron oder asynchron? 49

50 Ist ein API veröffentlicht, kann es nur noch sehr mühsam verändert werden. 50

51 Schauen wir uns das am Beispiel der Datenstruktur genauer an. 51

52 UI API Client API? 52

53 Lösungsansatz: kanonisches Datenmodell ermöglicht Wiederverwendung ermöglicht Austauschbarkeit Modellierung z.b. in JSON Schema 53

54 UI API Client kanonisches Datenmodell API 54

55 Probleme: kanonisches Datenmodell Enorme Analyseaufwände zieht sich durch alle Schichten Aufwände bei Änderungen 55

56 Praxis: kanonisches Datenmodell Inneres Datenmodell als erster Schritt zu kanonischem Modell Behauptung: Iterative Prozess führt langfristig zu kanonischer Form Neue externe Anforderungen wirken direkt auf internes Modell 56

57 Gute APIs sind schwer zu entwerfen 57

58 Lotto spielen ist einfach wenn man vorher die richtigen Zahlen kennt. 58

59 Modularisierung ist einfach, wenn man vorher die richtigen Schnitte kennt. 59

60 Empfehlungen? 60

61 It depends Leider auch dieses Mal keine 3 Bullet-Point Lösung 61

62 1 Personen- Team Kein API zwischen Frontend und Backend! 62

63 Pizzaschachtel-Team Besser kein API zwischen Frontend und Backend! 63

64 Pizzaschachtel-Team Muss ich jetzt TypeScript und Java können? Reicht nicht eine Sprache? 64

65 End-To-End-Entwicklung mit einer Sprache? DRY Validierung nur einmal Business Logik nur einmal 65

66 End-To-End-Entwicklung mit einer Sprache?? 66

67 Zwei große Teams API! Brauchen wir immer große Teams? 67

68 If you remember one thing Passt auf, dass ihr nicht versehentlich ein API baut, obwohl ihr keines braucht. 68

69 ??? Fragen?? Orientation in Objects GmbH? Weinheimer Str Mannheim

70 Vielen Dank für Ihre Aufmerksamkeit! Orientation in Objects GmbH Weinheimer Str Mannheim

Ähnliche Dokumente

Microservices. - Integration der Benutzeroberfläche - Version: Orientation in Objects GmbH. Weinheimer Str.

Microservices. - Integration der Benutzeroberfläche - Version: Orientation in Objects GmbH. Weinheimer Str. Microservices - Integration der Benutzeroberfläche - Version: 18.1 Orientation in Objects GmbH Weinheimer Str. 68 68309 Mannheim www.oio.de info@oio.de Ihr Sprecher Thorsten Maier Trainer, Berater, Entwickler