restapi 설계 시 식별자 처리

Question

restapi 개발 시 userId와 같은 유저 식별자를 인증 객체에서 꺼내서 바로 사용하는게 나을지프론트 등으로 이전에 반환해두고 매 요청마다 다시 파라미터로 받는 방식이 나을지 고민입니다.전자는 요청마다 반복되는 파라미터가 줄어든다는 장점이 있고,후자는 식별자를 api스펙에 포함시킴으로써 api 명세가 명확해진다는 장점이 있다고 생각됩니다.많은 조언 부탁드려요.,,,,,,

ExpoProvider · Accepted Answer

restapi 는 일반적으로, 로그인 세션이 아닌 JWT 기반으로 관리되어 왔던 게 일반적이었습니다. aaa.ai 도메인으로부터, aaa.bz 도메인으로의 api 요청이 발생할 수도 있기 때문입니다. 이 때, 인증정보를 공유하거나 전달해야 할 필요가 발생합니다. CORS 문제는 접어두죠.현재 질문하신 토픽은 REST API 제한입니다.무상태, stateless 를 지향하는 것이 REST 의 특성입니다. 따라서, '모든' 요청에 대해서 인증 정보를 제공해야만 합니다. 그것이 REST 입니다.REST는 무상태 원칙 때문에 모든 요청마다 인증이 필요합니다. 따라서 보통은 userId 같은 식별자를 API 파라미터로 매번 받기보다는, 토큰(JWT 등)에 담아서 서버가 꺼내 씁니다. 그래야 불필요한 중복이 줄고 보안상 안전하죠. 다만 다른 유저를 조회하는 API라면 파라미터로 userId를 받는 게 명세적으로 더 타당합니다.

톰소여 · Answer

Api key 발급하는 것이 일반적인 사례가 아닐까요? 재발급도 가능하고요.구글api 참고해보세요.

장독깨기 · Answer

인증 객체요.

포포치치 · Answer

JWT 형태의 토큰기반 인증이 아닌, 서버 Session 기반의 인증인가요?그렇다면, 프론트에서 보내는 값자체가 Sesseion 인증객체의 뽑아온값을 프론트로 보내놓고 그값을 resp api 호출시 다시 백엔드로 보내는 형태의 구조로 보이네요.이리 하셔도 문제는 없지만, 백엔드에서 프론트에서 보낸 식별자값의 대한 체크는 반드시 필요합니다.프론트에서 보내는 유저식별키가 조작될수도 있고, 인증세션이 그사이 만료된상태 일수도 있구요.이런부분 다 체크한다고 하면, 굳이 프론트에서 값을 보낼 이유가 있을까 합니다.뿌리값은 어째됐건 서버의 값이니, 프론트에서 보내는 값은 쓰이지 않습니다.프론트에서 보낸 유저식별키가 오염됐는지 아닌지 정도 체크?

restapi 설계 시 식별자 처리

4개의 답변

#restapi 목록