Przekierowanie poprzez ustawienie lokalizacji w nagłówku.

0

Mam metodę w API REST, która po wywołaniu powinna ustawić adres do przekierowania w nagłówku.

UriComponents uriComponents = uriComponentsBuilder.path("/signIn").build();

To jest ten kontroler z metodą

@RestController
@PreAuthorize("permitAll()")
@RequestMapping(value = "/register")
@Api(value = "Register API", description = "Provides a list of methods for registration")
public class RegisterRestController {
 
     @ApiOperation(value = "Activate the user with token")
     @RequestMapping(value = "/thanks", method = RequestMethod.GET)
     public
     ResponseEntity<?> confirmAccount(
        @RequestParam("token") String token,
        UriComponentsBuilder uriComponentsBuilder
     ) throws URISyntaxException {
          Optional<User> userOptional = userService.findByActivationToken(token);
 
          if(userOptional.isPresent()) {
             User user = userOptional.get();
 
             user.setActivationToken(null);
             user.setEnabled(true);
 
             userService.saveUser(user);
          } else {
             throw new ActivationTokenNotFoundException();
          }
 
          UriComponents uriComponents = uriComponentsBuilder.path("/signIn").build();
 
          return ResponseEntity.created(uriComponents.toUri()).build();
    }
}

Nie ma przekierowania po wywołaniu adresu strony https://zapodaj.net/fa61bfc5732f3.png.html. Zrobiłem to dokładnie tak samo jak w tym temacie na Strack Overflow STACK. Adres wywołuję za pośrednictwem łącza w skrzynce pocztowej https://zapodaj.net/e0e5eb8ad52bf.png.html. Ustawiona lokalizacja w nagłówku nie daje jakiegokolwiek efektu. Nagłówek 'locale' jest ustawiony https://zapodaj.net/5aea40b635dd7.png.html/

2

Mamy tu dwie różne sprawy:

  1. HTTP 201 Created to nie jest przekierowanie. Nagłówek Location służy w tym typie odpowiedzi do podania adresu utworzonego zasobu. Przekierowanie rozpoznaje się po statusie HTTP 3xx.
  2. Jeśli to jest REST API, to ono nie służy do tego, by adresy URL wklejać do maili, by w nie ludzie klikali, by potwierdzić rejestrację, by ich przekierowało na stronę logowania. Rozkoduj sobie skrót API: Application Programming Interface.

Innymi słowy, albo robisz normalną stronę dla użytkownika, albo API dla aplikacji. Jak chcesz mieć API, to musisz jeszcze dodać jakąś aplikację, z którą użytkownik będzie wchodził w interakcję. Użytkownik powinien w mailu dostawać odnośnik do tej Twojej aplikacji, a ona pod spodem powinna wołać Twoje API i odpowiednio interpretować odpowiedź.

0

OK. Próbuję to zrozumieć. Czyli masz na myśli, aby link przekierowywał do aplikacji do zwykłego kontrolera na określony adres, a metoda kontrolera pod tym adresem powinna np. za pomocą RestTemplate wywołać adres API, pobrał odpowiedź i odpowiednio to zinterpretował? Czyli taki normalny @Controller ma pośredniczyć między komunikacją z @RestController?

W sumie to nie do końca Ciebie rozumiem. Mówiąc 'musisz jeszcze dodać jakąś aplikację, z którą użytkownik będzie wchodził w interakcję.' na przykładzie tego linka do aktywacji tokena, to link ma kierować na adres jakiegoś kontrolera, który będzie pobierał dane z API?

0

Chodzi o to, że to, co próbujesz zrobić, to nie jest REST i mylisz pojęcia. REST to pewna filozofia projektowania komunikacji pomiędzy różnymi aplikacjami w sieci z wykorzystaniem protokołu HTTP oraz jego mechanizmów. Ty chcesz zrobić interakcję człowieka z maszyną za pośrednictwem przeglądarki. Chciałem, abyś zauważył i zrozumiał tę różnicę.

API służy do komunikacji między aplikacjami i jeśli jest zaprojektowane zgodnie z zasadami REST, to łatwo jest napisać aplikacje, które ze sobą współpracują. Przykłady takich zasad:

  • adresy URL to rzeczowniki reprezentujące zasoby, np. /tralala/user/17
  • metody HTTP to czasowniki do manipulacji zasobami, np. DELETE /tralala/user/17

Przeglądarka interpretuje HTTP według trochę innej filozofii: adresy URL to dokumenty, pomiędzy którymi nawiguje użytkownik.

Zauważ, że podsunąłem Ci dwa pomysły:

  • zrobić zwykły, "tradycyjny" kontroler, który aktywuje użytkownika i robi przekierowanie HTTP 301 Redirect - po to, by przeglądarka przerzuciła użytkownika gdzieś indziej,
  • kombinować z dwoma aplikacjami:
    1. aplikacja A obsługuje żądanie /register z przeglądarki,
    2. aplikacja A wysyła do aplikacji B z API REST-owym żądanie aktywacji konta,
    3. aplikacja B wykonuje operację i wysyła HTTP 20x cośtam,
    4. aplikacja A odbiera odpowiedź i wysyła HTTP 301 Redirect użytkownikowi.

Słusznie zauważasz, że druga opcja w Twoim przypadku to przerost formy nad treścią, bo z kontekstu wynika, że piszesz jeden, monolityczny backend. Zostaje Ci zatem opcja nr 1 :).

1 użytkowników online, w tym zalogowanych: 0, gości: 1