강사님 rest, http api 설계에 대해 궁금한점이 있습니다!

안녕하세요 김영한 강사님!! 이렇게 또 질문을 올리게 되었습니다..!

토이프로젝트로 api를 설계할때마다 너무나도 궁금한점들이 있었습니다.

간단한 예제로 회원 정보 api 설계로 예를 들어보겠습니다!

.

 회원 조회 api 설계라고 하면 보통 /members/{id} 이런식으로 알고 있습니다.

.

Spring Security를 이용해 jwt나 세션을 사용하면 Principal 객체에 회원 데이터가 들어있어서

이를 이용해  /members/me -> 이런 api 설계도 가능했었습니다

(jwt decode 된 정보나 세션 정보를 확인해서 정보조회)

.

클라이언트 입장에선

로그인 후 회원 정보를 보고싶으면 회원조회를 요청하는 uri 주소를 띄워줘야 하는데 회원 리소스의 식별 값을 알아야지 조회가능 하지 않나? 라는 생각이 들었습니다.

.

Admin 페이지에서의 예를 들어보면

회원들 관리를 위해 전체 회원 목록 조회를 하면 회원 entity들을 dto로 반환하고 hateoas를 이용해 각각의 회원 정보를 조회하는 uri를 PagedResourcesAssembler를 이용해 각 회원마다 만들어 주었었습니다.

(예시를 들자면 회원 목록 조회후 @Id 값들로 회원 조회, 게시판 글 목록 조회 후 @Id 값들로 게시판 글 조회, 주문 목록 조회후 @Id 값들로 주문 조회 이런식입니다!)

ex) 

하지만 로그인한 일반 유저 입장에선

-그냥 세션을 이용한다면 세션에 setAttribute한 값을 가져와서 회원을 조회해서 정보를 나타내주면 되고

-jwt를 이용한다면 decode된 정보를 바탕으로 회원을 조회해서 정보를 나타내주면 되는데

/members/{id} 로 api 설계를 하고 api 문서를 적어놨다고 하였을때 클라이언트 쪽에선 어떻게 개발을 하는지 궁금합니다.

(보통 실무에선 restful을 지키기가 힘들기 때문에 보통 지켜지지 않으며 개발이 된다고 하신 답글을 보았었습니다!)

.

- /members/1 이라고 했을때 1번인걸 클라이언트가 어떻게 알고 회원 정보를 보는 페이지로 가는 uri를 적는걸까?

-> 서버로 로그인 요청을 보내면 서버에서 1번 응답을 줘서 클라이언트에 따로 저장시켜놓는건가?

.

이런 생각들입니다..! 제가 이부분에선 잘못 생각하고 있을수도 있지만 이상하게 헷갈리는 부분은 꼭 알고 가고싶어서 여쭤보게되었습니다.

구글에 찾아봐도 설계만 딱 있을뿐 저에게 답이 되는 부분은 찾지 못하였습니다..ㅜ

.

그래서 정리하자면

1.  /members/me -> Principal 에 저장된 정보로 회원조회 하는 설계랑

/members/{id} -> @PathVariable id 값으로 회원 조회 하는 설계가 명확히 어떤 측면에서 장단점들이 있고 제가 앞에서 말씀드린 내용의 대한 것과 제가 어떤 부분을 잘못 알고있는지 궁급합니다!

2. 보통 rest가 아닌 실무에서의 http api 설계를 할때 해당 페이지에서 이동 가능한 link 까지 포함해서 응답을 주는지 궁금합니다!

(회원 정보 페이지 라고 한다면 회원 정보 페이지에선 회원 수정, 회원 탈퇴 의 링크가 있다면 이걸 포함시켜서 응답을 해야하는지)