WIP Feature/first api connection #13
Conversation
|
|
||
| @Bean | ||
| public SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) { | ||
| http.authorizeExchange().anyExchange().permitAll(); |
There was a problem hiding this comment.
Ich glaube wenn du hier .csrf().disable() nach http.authorizeExchange() hängst, kannst du dir die @CrossOrigin Annotation im ReportBookletCreationService und somit auch im ganzen restlichen Code sparen
There was a problem hiding this comment.
Nope funktioniert leider nicht.
.crsf().disable() und http.autohrizeExchange() bringen nichts.
Nur @crossorigin bringt was
|
|
||
| @SpringBootApplication | ||
| @SpringBootApplication(exclude = { SecurityAutoConfiguration.class }) |
There was a problem hiding this comment.
Wieso musstest du dies excluden?
There was a problem hiding this comment.
Das war einer der versuche den Network Error zu fixen.
| @CrossOrigin(origins = "http://localhost:8081") | ||
| @RestController | ||
| @RequestMapping("/api") | ||
| public class ReportBookletCreationService { |
There was a problem hiding this comment.
Genau genommen wäre das ein Controller, in etwa ReportBookletController die Serviceschicht dient zu Operationen mit Repositories bzw als Zwischenschritt: Controller mit Restapi ReportBookletController -> ruft Service Methode auf aus ReportBookletService -> führt Repository oder ggf. andere Operation aus ReportBookletRepository.
Im Controller und Service haben wir dann verschiedene Apis & Methoden wie z.B. delete save get und würden dann nach Entitäten untergliedern, also ReportBookletController und -Service welchealle nötigen Operationen beinhalten
There was a problem hiding this comment.
Habe für die Änderung nicht so tief gedacht. ReportBookletCreationService sollte als Beispielklasse für "proof of concept" dienen für mich selber :'D
Aber danke für die Erläuterung :)
|
|
||
| @CrossOrigin(origins = "http://localhost:8081") | ||
| @RestController | ||
| @RequestMapping("/api") |
There was a problem hiding this comment.
würde hier ("/api/booklet") oder so bevorziehen
There was a problem hiding this comment.
Wie schon erwähnt war dies als Proof of concept gedacht. Aber guter Vorschlag.
| @RequestMapping("/api") | ||
| public class ReportBookletCreationService { | ||
|
|
||
| @RequestMapping( path = "/") |
There was a problem hiding this comment.
@GetMapping kannst du auch direkt schreiben, der Parameter path wird oben an den RequestMapping Pfad gehangen und kann hier auf jeden Fall weggelassen werden. Wenn wir oben ("/api/booklet") haben koennen wir z.B. zwei Apis ohne expliziten path schreiben, die eine mit @GetMapping annotiert und die andere mit @PostMapping, so wird dann einfach beim Aufruf von /api/booklet am Requesttype entschieden welche Methode aufgerufen wird, und wir koennen einfach get und post auf /api/booklet aufrufen
There was a problem hiding this comment.
Das war mir nicht klar. Habe sehr viele unterschiedliche Beispiele online gesehen, aber nun weiß ich wie es besser zu nutzen ist.
|
|
||
| @RequestMapping( path = "/") | ||
| public Object greeting(){ | ||
| return "test"; |
There was a problem hiding this comment.
Ach nice, muss das garkeine ResponseEntity sein?
There was a problem hiding this comment.
Soweit ich weiß nicht.
ResponseEntity sind natürlich im zusammenspiel mit JPA besser, aber der Rückggabetyp kann vermutlich jeder Content-Type sein.
There was a problem hiding this comment.
Nicer PR! :^) Wir könnten das Setzen der axios URL und der header noch in eine eigene .js outsourcen. Und allgemein sind feste Ports im Code immer not so nice, die holen wir besser später dann aus den environment variables. Aber nice, war das dein erster vollständiger backend-api-frontend flow?
|
Ich hätte vielleicht aufräumen sollen bevor ich einen PR mache :D |
|
Bezüglich Axios und die neue .js, hatte ich auch schon im Hinterkopf. Für PoC hats so gereicht. |
dkraemerwork
changed the title
application configurations
|
Bitte um erneutes feedback. |
please verify and pull it in man