개발자
오늘 회사에서 React로 개발을 하다가 궁금한 점이 생겼습니다. 지금은 post 요청을 보내면 응답에 대한 상태와 result 메시지가 응답으로 와요(e.g. 'ok', '처리 되었습니다.'). 이러한 성공 여부만 알 수가 있어서, 새로운 데이터가 생성될 때마다 리페치 함수를 따로 만들어 get 요청을 했습니다. 그런데 가만히 생각해 보니 응답에 변경된 새로운 데이터가 포함돼서 오면 좋을 것 같더라구요. 이렇게 되면 '통신 요청수도 줄어들고, 최신 상태를 알 수 있어서 리페칭 할 필요 없이 리렌더링도 할 수 있겠다.'라고 생각을 했고, 코드도 더 깔끔하게 만들 수 있을 것 같더라구요. 그런데 이게 아무래도 백엔드에 추가 작업이 들어가는 거라 쉽게 요청을 드리기도 고민이 되었고, 뭔가 모를 찜찜함에 프론트엔드 오픈채팅방에 여쭤보았습니다. 와..근데 답변을 주신 모든 분들이 저처럼 get으로 처리를 하시더라구요. 다들 post 응답 바디의 데이터를 사용하는 데에 부정적인 생각은 없지만, post는 생성에, get은 데이터를 조회하는 것에 대한 '역할'을 더 중요하게 생각하시는 것 같았습니다. 따라서 현재 제 생각은 클라이언트에서 처리를 하고, 좀 더 메서드의 역할에 맞게 get으로 데이터를 조회하는게 맞다고 생각해요. 그런데 만약 처음부터 응답에 변경된 데이터가 포함되었다면, 그걸 사용했을 것 같단 생각이 들어요. 그래서 더 다른분들의 의견이나 경험을 알고 싶습니다. 제가 모르는 장단점에 대해서 좀 더 알고 싶어요! 혹시 여러분들은 어떻게 처리하시고, 해당 내용에 대해 어떻게 생각하시나요?
답변 9
인기 답변
삭제된 사용자
2023년 11월 30일
Method의 역할이 아닌 데에터베이스의 Consistency 관점에서 이야기를 드려볼게요. 사실 대부분의 경우에 Create / Update operation에 대해서 생성된 resource를 응답에 포함하지 않고 성공 여부만 반환하는 구현은 “틀린 구현” 입니다. “틀린” 이라는 단정적인 표현을 사용하기 위해선, 상황 정의를 명확하게 해야겠지요? 제가 정의하는 상황은 단일 서버가 아닌 여러 서버가 동작하는 분산시스템에서의 상황입니다. 그렇다면 분산 시스템에서 위와 같은 구현은 왜 틀렸다고 할 수 있을까요? 이를 이해하기 위해서는 데이터베이스의 Consistency에 대해서 먼저 이해해야 합니다. Consistency란 간단히 말해서, 내가 방금 수행한 write작업이 read될 수 있는 상황이 되기까지 지연이 있을수 있다는 의미입니다. 다르게 말하면, 내가 방금 insert한 row를 바로 이어서 select를 하면 없는 row라는 결과가 나올 수 있다는거죠. 이는 데이터베이스가 scalable한 읽기 성능을 제공하기 위해 하는 선택입니다. 많은곳에서 빠르게 읽기 요청 들어온다면 단일 서버에서 감당하기 힘들어집니다. 이럴때 데이터베이스 복제본을 만들어 읽기 서버를 확장하는데요. 이를 읽기 서버의 수평 확장 이라고 하고, 읽기 서버들은 복제본이기에 쓰기 서버에서의 변경이 읽기서버에 반영되기까지 지연이 될 수 있습니다. 이를 흔히 Replication Lag이라고 하죠. 여기서 RDBMS만 접해보신 분들은 위 내용이 이해가 되지 않을 수 있습니다. 방금 insert한 데이터 select하면 항상 잘 나오는데? 라고 생각하실 수 있죠. 하지만 그 경우는 쓰기서버에 insert / select하는 경우에만 성립합니다. 만약 insert를 한 이후 읽기 서버에 select를 하면 lag으로 인해 데이터가 없을 수 있죠. 이는 매우 흔하게 일어나는 일입니다. 반대로, 모든 상황에서 쓰기 직후 읽기를 보장한다면 ’Strong Consistency를 지원한다‘ 라고 합니다. 많은 분산 데이터베이스는 기본적으로 Strong Consistency를 지향하지 않습니다. 즉, 위와 같은 읽기 지연은 매우 일반적이라는거죠. MongoDB나 Cassandra, DynamoDB등의 서버 또한 Quorum(정족수)를 어떻게 설정하냐에 따라서 Strong consistency를 지원할수도, 하지 않을수도 있죠. 하지만 대부분 Consistency를 포기하고 가용성을 지향하게 설정합니다. RDBMS를 사용하는 경우 서비스의 성장에 따라 Read Replica를 추가하는 경험을 많이들 하실겁니다. 이 또한 Consistency를 포기하고 데이터베이스를 분산 데이터베이스로 만드는 작업의 일종이죠. 다시 Create / Update 요청과 Get 요청의 주제로 돌아와봅시다. 분산 데이터베이스를 사용한다면 당연히 Get 요청은 읽기 서버에 요청하게 될겁니다. 이 경우 직전에 있던 수정사항이 반영이 안되어있을 확률이 있습니다. 99.999%의 Consistency를 제공하더라고 10만번에 한번은 없을 수 있는거죠. 이것을 해결하는 올바른 방법은 두가지가 있습니다. 1. Create / Update 요청에서 응답에 변경된 리소스를 담아준다. 2. 이벤트 기반 설계를 적용하여 생성 결과가 모든 서버에 전파되면 클라이언트에게 이벤트를 푸시해준다. 질문자님의 케이스에는 1번이 정답인거죠. 그렇다면 Strong Consistency를 사용하는 환경, 즉 Read Replica 없이 단일 RDBMS를 사용하는 경우라면 결과에 리소스를 담지 않아도 될까요? 제 의견은 No입니다. 이유는 다음과 같아요. 1. 지금은 Read Replica가 없어도 언제가 추가될 수 있습니다. 작은 습관으로 큰 수정을 막을 수 있어요. 2. 어떤 곳에서는 리소스를 담아서 내려주고 어떤곳에서는 안담아주고 하는식으로 일관성 없는 설계를 할 필요가 없습니다. 리소스를 담아서 응답을 주는 방식으로 통일해두는게 API를 읽는 입장에서도 좋습니다. 작성자님은 프론트엔드 엔지니어이시지만 백엔드 엔지니어링 관점에서 이야기를 드리면, 백엔드 시스템 디자인은 분산시스템 설계의 한 분야입니다. 항상 내서버, 데이터베이스, 의존하는 컴포넌트가 분산 환경에서 운영될 수 있다는것을 가정해야하죠. 작성자님이 제안하신 방향이 백엔드 엔지니어링 관점에서 옳은 방법이니 위와 같은 내용으로 팀을 설득해 보시면 좋을 것 같아요. 위에 이야기한 분산 데이터베이스 대해서 더 자세히 알고싶으시다면 다음과 같은 내용을 공부해보세요. - CAP Theorem - MySQL Replication - Cassandra DB - Raft 합의 알고리즘
김병연(Vintz)
작성자
프론트엔드 개발자 • 2023년 12월 03일
안녕하세요, 건우님. 말씀하신 내용의 분야를 잘 모르다 보니 이해하는 데에 시간이 좀 걸렸습니다. 덕분에 고민해 보는 시간도 많이 가질 수 있었어요! 정말 감사합니다. GET은 데이터 조회, POST는 데이터 생성, PUT은 데이터 수정 등 이런 것들이 메서드의 '역할'이고 응답에 업데이트된 리소스를 응답 본문에 포함시키는 건 옵셔널한, 즉 구현하는 개발자의 선택 사항이며, 그리고 그 구현 방식에서 Create / Update 시 변경된 리소스를 담아주어야 한다는 것을 건우님이 잘 설명해주셔서 이해가 되었습니다. 건우님이 말씀하신 것처럼 분산 시스템의 경우 데이터 일관성을 위해 즉시 생성된 리소스를 응답하는 것이 좋고, Strong Consistency를 지원하는 환경인 단일 RDBMS 사용 시에도 추후 읽기 전용 복제본이 추가될 가능성을 고려하고, 일관된 API 설계를 위해 필요하다면, 왜 Create / Update 시 응답에 변경된 리소스를 포함하지 않는 경우가 있는 걸까요? 제 생각엔 민감한 정보가 포함되어 있지 않은 경우라면, 서버 비용 절감에 있지 않을까요? 요즘은 대부분의 클라이언트들이 하드웨어 성능이 좋아져서 서버가 아닌 클라이언트에서 데이터를 가공하고, 렌더링 하는 것 같다는 생각이 듭니다. 이러면 높은 성능의 서버가 필요하지 않으니까 비용이 절감되지 않을까요..? 그리고 같은 POST API에서 하나의 컴포넌트는 전체 리스트의 데이터가, 또 다른 하나의 컴포넌트는 리스트 중 일부 데이터만 필요할 때는 GET과 POST를 구분해서 API를 디자인하는 게 더 나은 방법이지 않을까 생각합니다. 저는 이렇게 두 가지가 생각이 났습니다. 혹시 건우님은 어떻게 생각하시는지 궁금합니다!
익명
작성자
2023년 12월 04일
제 답변이 고민의 기회가 되었다니 다행이라고 생각됩니다. 추가로 주신 질문에 대한 답변도 추가해보겠습니다. "왜 Create / Update 시 응답에 변경된 리소스를 포함하지 않는 경우가 있는 걸까요?" 라는 질문에 대해서는 조심스러운 마음은 있지만, 조금은 aggresive한 답변을 드려보려고 합니다. 이에 대한 답변은 "대부분이 무지에서 온 잘못된 설계의 예시" 라고 말씀 드릴 수 있을 것 같습니다. 물론 응답에 변경된 리소스를 포함하지 않는 모든 케이스가 틀린 설계라 말할수는 없을 것 입니다. 하지만 실제로 기술적인 설계를 하다보면 응답에 포함되어야 하는 경우가 대부분일 것 입니다. 대부분의 경우가 응답에 리소스를 포함해야하고 몇몇 케이스에서 포함하지 않는 경우가 있는 것이라고 보는게 맞을겁니다. 응답에 리소스를 포함해야 하는 케이스는 원 답변에서 길게 설명해 보았으니, 포함하지 않는 케이스를 소개해보는게 도움이 될 것 같네요. 1. UI 지향 API를 설계했고, 생성 결과를 UI에 표시하지 않는다. 대부분 사람들이 REST API를 설계한다면 리소스 지향 API를 설계할 것 입니다. 리소스 지향 API라 하면 두개의 화면 A와 B 모두에서 C라는 리소스를 생성하는 기능이 있다면 A, B 화면 모두 같은 API를 사용하는 설계입니다. 이 경우에는 API를 작성하는 입장에서 응답 스키마를 DB에 저장된 형태를 기준으로 설계를 하게 되고, UI에서는 필요한 데이터를 여기저기서 끌어다 쓰는 방식으로 데이터를 조합하게 되죠. 하지만 UI 지향 API 에서는 응답 스키마를 해당 UI를 위해 설계하게 됩니다. 위와 같이 화면 A와 B 모두 같은 리소스 C를 생성할 수 있다 해도, 각 UI 별 로 입력 필드가 다르고 결과에서 보여주는 UI가 달라질테니 리소스 C를 생성하는 API도 A를 위한 API, B를 위한 API 따로 만들게 됩니다. 만약 BFF (Backend for Frontend)를 사용하는 아키텍처라면 BFF에서는 UI 지향 API를 제공하고 뒷단에서 데이터 지향 API로 설계된 마이크로 서비스를 호출하는 구조가 일반적일겁니다. 다시 응답에 리소스를 포함하는 이야기로 돌아와서, UI 지향 아키텍처에서 다음과 같은 순서의 UI를 지원하는 API를 만든다고 가정해보겠습니다. 인스타그램과 같은 소셜미디어 포스팅을 상상해봅니다. - 별도의 페이지 / 모달에서 포스트를 업로드합니다. - 업로드가 완료되면 메인 피드로 돌아갑니다. - 새로고침 하면 내 포스트가 알고리즘에 의해 피드 위쪽으로 자연스럽게 올라와 있습니다. 이 경우 업로드 이후에 UI에서 별도로 피드 새로고침을 진행하게 될 것 이기에 응답에 생성된 포스트를 포함하지 않는 경우가 있을 수 있습니다. 다만 원 답변에서 언급한 복제 지연 문제는 여전히 있을 수 있기에 피드 새로고침에서 업로드 된 포스트가 바로 나오지 않을 수 있습니다. 이 경우, 유저가 새로고침을 한다면 해결되는 문제이고 발생 빈도가 낮기에 받아들일 수 있는 문제로 볼 수 있습니다. 다만 이러한 문제가 비즈니스에 큰 문제가 되는 케이스에선 선택할 수 없는 구현이 될것입니다. 이처럼 UI지향 API에서는 응답에 리소스가 포함이 되지 않을수도 있지만 이러한 경우는 매우 제한적입니다. 2. 실제로 데이터가 언제 생성될지 알 수 없는 비동기 설계를 지향하고 있다. 원 답변에서 언급한 이벤트 기반 설계에 대한 예시 인데요. 커머스 API를 예로 들어 보겠습니다. UI를 통해 주문 요청이 들어오면 이후 주문서 제출, 재고 확인, 카드사 결제 요청, 주문 결과 저장, 로깅 등등 수많은 후속 작업이 진행됩니다. API에서 이러한 과정을 모두 끝내고 응답을 주면 응답속도는 매우 느려지게 됩니다. 웹서비스에서 느린 응답은 매우 많은 부작용을 낳습니다. 그렇기 때문에 이벤트 지향 설계에서는, 요청이 들어가면 내부에 이벤트버스로 요청을 발행하고 즉시 "주문 요청 성공" 응답을 내리게 됩니다. 이 때 주문은 아직 생성되지 않은 상태이며, 요청만 한 상태인거죠. 만약 중간에 에러가 발생하거나, 카드 결제가 실패하더라도 클라이언트는 모르게 되는 상황인거죠. 이를 위해 서버는 모든 처리가 완료되면 클라이언트에게 완료 이벤트를 푸시해주게 됩니다. 이 이벤트를 통해 클라이언트에서는 완성된 (혹은 실패된) 주문을 받아가게 되는거죠. 이를 국소적으로 보면 생성 API의 응답에는 리소스가 포함되지 않으니 하나의 예시로 볼 수 있는것이죠. 두번째 서버 성능과 비용 절감 측면에서 말씀드리면 필드 하나 두개 줄인다고 해서 서버 비용 절감에 크게 도움이 되지 않습니다. 그런 최적화를 할 시간에 차라리 응답에 압축을 적용하거나, HTTP 2 or 3을 도입하거나, 바이너리 기반 통신 프로토콜을 채택하는것이 도움이 많이 됩니다. 민감한 정보 또한 비용절감에 관여되지 않구요. 데이터 렌더링은 서버와 클라이언트 모두가 합니다. 서버는 DB에 있는 데이터를 JSON이나 Protobuf같은 직렬화 데이터로 변환하고, 클라이언트는 이를 UI로 렌더링합니다. 성능상 이점에 변화점은 없습니다. 일부 다른분들의 답변을 부정하는 형태가 되어서 조심스러운 답변이었지만 필요한 이야기라 생각해 추가로 적어보았습니다. 질문자님의 고민과 성장이 도움이 되었으면 좋겠습니다!
Ed
프론트엔드 개발자 • 2023년 12월 05일
많이 배워갑니다 👍👍
김병연(Vintz)
작성자
프론트엔드 개발자 • 2023년 12월 07일
건우님 덕분에 퇴근 시간에도 즐겁게 집에 갈 수 있었습니다. 이렇게 어려운 주제로 대화를 나눠도 재밌을 수가 있네요. 말씀하신 키워드로 계속 찾아보고, 공부하고, 더 고민해보고 나서 블로그 글도 작성해보려고 합니다. 감사의 말씀드립니다! 현재 회사에서는 저랑 같이 프로젝트를 하는 5년 차, 10년 차 이상의 백엔드 개발자 두 분이 계십니다. 아무래도 팀 전체에 이런 공감대를 만들고, 프로젝트가 어느 정도 많이 진행이 된 상태에서 서버쪽 API들을 수정하기에는 리소스가 많이 들 것 같아서 망설여지긴합니다..우선 제가 기반을 더 쌓아야 할 것 같아요. 하지만 이제는 건우님 덕분에 어떤 상황에 어떻게 API 설계를 해야할지 감이 잡혀서 추후 기회가 생긴다면 자신있게 말할 수 있을 것 같습니다. 좋은 인사이트를 주셔서 정말 감사드립니다!
인기 답변
각 http 메소드 마다 역할이 있고 그 역할을 명확히 구분해줘서 설계하는게 좋을것 같습니다 Post 면 데이터를 insert 하고 그 insert 하는 작업의 결과를 응답해주는 도메인 범위가 명확한 api를 설계하는게 좋다고 생각합니다 질문자님이 하고계신대로 따로따로 post, get 요청 하시는게 좋을것 같아요
김병연(Vintz)
작성자
프론트엔드 개발자 • 2023년 11월 22일
그렇군요..! 역시 역할에 맞게 사용하는 것이 모범 사례가 아닌가 싶습니다. 의견 정말 감사드립니다!!
인기 답변
저희 프로젝트에서 이번에 10년정도 이전에 개발된 백엔드 서버와의 통신도 겸하고 있는데 post에 ok를 줘도 get시 서버에 데이터에 반영이 안되는 경우가 있더라구요.. 😥 심지어 post에 ok임에도 서버 내에서 실패하는 경우도 있는지 영영 바뀌지 않는경우도.. 이런 경우에도 get으로 실제 반영이 됬는지 이중 체크하는 의미로 생각하면 분리 하는 것이 좋다고 생각합니다
김병연(Vintz)
작성자
프론트엔드 개발자 • 2023년 11월 22일
그렇군요..! post로만 처리 했다면 무심코 지나갈 수도 있겠네요. 좋은 경험 공유 감사드려요!! 👍
인기 답변
제가 큰 경험이 많다거나 실력이 막 월등하다거나 하는것은 아니지만, 일반적으로 HTTP 메서드의 그 의미에 충실하려고 하고 있습니다. POST 의 경우는 따로 응답 body를 내리지 않고 HTTP status code, 혹시 오류가 났을 때는 에러메시지 정도를 리턴하는 것 같습니다. 잘못해서 serialize step을 잘못 설계하거나 미처 생각하지 못했을 경우에는 괜히 민감한 데이터가 같이 리턴될까 싶어서요. 그 POST 리퀘스트 이후에 GET 을 만약 또 호출해서 같은 정보를 가져오는 UI/UX가 있다면 프론트 개발자분들과 협의 후에 유동적으로 응답을 조절하게 설계했었습니다.
김병연(Vintz)
작성자
프론트엔드 개발자 • 2023년 11월 24일
그렇군요..! 좋은 의견 감사합니다! 궁금한 게 하나 있습니다. 내용 중에 직렬화 부분에서 말씀하신 의도가 혹시 '서버단에서 데이터를 조작하는 게 찜찜하다.' 정도로 이해해도 될까요? 🧐 서버단은 잘 모르다보니 여쭤봅니다!
빈센트
Backend Engineer • 2023년 11월 24일
네 맞습니다. 예를 들어보겠습니다. 데이터베이스 어떤 테이블의 컬럼이 다른 데이터에 비해 민감하거나 암호화 되어있는 값을 가지는 컬럼이라고 생각해보겠습니다. 그냉 응답으로 내리기는 보안상의 이슈가 있을 수도 있겠습니다. 만약 백에서 해당 테이블의 row 를 추가해서 그 row의 값을 그대로 리턴 받아 프론트로 전달하는 코드가 있다고 가정하면, 민감한 데이터가 (암호화되어있다고 할지라도) 응답에 포함되어 내려가게 됩니다. 서버에서 이런 민감한 데이터가 내려가지 않게 리턴하기 전에 객체를 검사해준 후, 전송가능한 형태로 파싱 해주어야 합니다.(이것이 직렬화) 이때 직렬화 관련된 코드를 잘못 작성하거나 이슈가 있으면 민감한 데이터가 의도와 다르게 내려갈 수 있을텐데 그것에 대한 문제를 저는 함축적으로 "직렬화를 잘못 설계하였다" 라는 워딩을 사용했다고 생각해주시면 감사하겠습니다 ps. 제가 아직 주니어라 글에대한 피드백 언제든 감사합니당
김병연(Vintz)
작성자
프론트엔드 개발자 • 2023년 11월 24일
예시까지 들어주셔서 감사합니다! 그렇다면 GET 요청에서도 마찬가지로 POST 요청에서 생성된 민감한 정보에 대해 필터링을 하고 직렬화를 해줘서 클라이언트에 보내줄텐데, 결국 서버단에서 데이터를 추가하고 보내주는건 같지않나..?라는 생각이 들어요. 이 점에 대해서는 어떤 차이가 있는지 궁금해요! 아..! 판도라님의 요지는 하나의 메서드에서 생성과 조회를 둘 다 하려고 하다보면 실수할 가능성이 커지니까 분리하는 게 좋다!가 맞을까요? 제가 잘 이해를 한건지 모르겠네요 🤣
빈센트
Backend Engineer • 2023년 11월 24일
네 맞습니다. 제가 화술이 좀 부족했던것 같습니다. 말씀해주신대로의 의미도 분명히 있고, POST/GET 과 같은 http method 의 semantics 도 엄연히 다르다고 판단해서 저렇게 적었습니다. 병연께서 잘 요약해주셔서 제쪽에서 오히려 생각이 같이 정리되는 것 같습니다 감사해요 :)
김병연(Vintz)
작성자
프론트엔드 개발자 • 2023년 11월 24일
저도 덕분에 생각을 깊게 해볼 수 있어서 좋았어요! 정말 감사합니다 판도라님!! 😁
만약 다른 플로우에서 그 post를 호출해야 하는 경우가 생기면 어떻게 될까요? 그 플로우에서는 업데이트된 내용이 전혀 필요하지 않을 수도 있고 반대로 좀더 많은 데이터가 필요할 수도 있겠죠 현재로 보면 response에 필요한 값을 추가하는 것이 효율적으로 보일수 있겠지만 역할(기능)이 섞여버리게 되면 서비스의 기능이나 범위가 확장됨에따라 오히려 발목을 잡을 수도 있을껍니다 우리는 서비스가 언제 어떻게 변화할지 알수없기 때문에 가능한 역할에 맞는 기능들을 구성해 두고 이를 이용하도록 해야하지 않을까 싶습니다
minw
백엔드 개발자 • 2023년 11월 21일
혹시나 오해하실까봐, 제 의견은 확장성을 고려해서 API 디자인을 하자는 것이지 post에는 절대 관련 데이터가 포함되면 안된다를 말하고자 한것은 아닙니다 ㅎㅎ
김병연(Vintz)
작성자
프론트엔드 개발자 • 2023년 11월 22일
아하..서비스의 확장성까지는 생각을 못해봤는데 덕분에 알게 되었습니다!! 유연하게 대처하기 위해서는 확실히 그렇겠네요. 🤔 애초에 역할을 확실히 구분해서, 서비스의 확장성까지 고려하는 게 좋겠네요! 정말 감사드립니다!!
경우에 따라 다르겠지만 넣은 데이터 그대로 insert 되고, get할때 와 동일한 스키마 형태인 경우, 200응답이 오면 프론트에서 get할때 값을 이미 가지고 있을테니 바로 화면에 표출하면 될수도 있어요.
그래서 Rest를 우리가 정말 잘 사용하고 있느냐에 대답을 YES라고 할 수 없는게 이런 부분이라고 생각하는데요~ 생성된 URL을 헤더의 Location으로 지정해서 응답할 수 있겠습니다! https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201 저는 그때그때 마다 다른데 생성 이후 생성된 URL로 이동해야 하는 비즈니스 로직이 있는 Post API call을 하는 경우 응답을 줍니다. 사실 이때도 header로 주지 않고, body로 응답하는것도 조금 생각해볼 필요가 있네요.
김병연(Vintz)
작성자
프론트엔드 개발자 • 2023년 11월 25일
오..생성 이후 생성된 URL로 이동해야 하는 예시로는 블로그 글 작성이 있겠네요! 답변 주신 내용으로 몇 가지 알게 된 사실은 1. POST 요청에 의해 서버에 리소스가 생성된 경우 이상적인 응답은 201(created) 상태 코드를 포함하는 것 2. Location 헤더에 새로 생성된 리소스의 URI를 가리키는 것은 HTTP 스펙에서 표준적인 방법이라는 것인데요! 이렇게 조회해야할 리소스의 위치를 명확하게 알려주면 프론트 입장에서도 좋겠네요. 덕분에 새로운 사실 알아갑니다!! 혹시 틀린 내용이나 피드백이 있다면 언제든지 알려주세요. :)
프론트 단에서 데이터를 캐싱할 수 있다면 reponse로 값을 주는게 좋구요. 그게 아니라면 성공, 실패에 대한 reponse만 주고 데이터를 get하는 api를 콜해서 UI를 refresh 하는 방법이 좋습니다.
김병연(Vintz)
작성자
프론트엔드 개발자 • 2023년 12월 10일
의견 감사합니다!!
UX의 관점에서 보자면, 응답에 데이터를 받는 것이 좋습니다. 일반적인 rest api + csr 상황이라면 fetch data를 state에 담아 사용하므로 state를 업데이트해서 화면을 갱신하는 것이 페이지 갱신보다 ux에 보다 더 유리하죠. 그러려면 추가/수정한 데이터를 응답에서 받는 것이 좋구요. optimistic update 방식으로 해도 match를 확인하기 위한 로직이 필요한데 이때에도 응답에 ok 하나 있는 것보단 데이터 그 자체를 보내주는 것이 보다 유효한 검증이 되겠구요. restful 하다는 것이 protocol을 적확하게 쓰라는 말인데, 생성에 대한 요청에 그 생성이 어떻게 들어갔는지를 응답에서 받아보는 것이 의미를 훼손한다고 할 순 없습니다.
지금 가입하면 모든 질문의 답변을 볼 수 있어요!
현직자들의 명쾌한 답변을 얻을 수 있어요.
이미 회원이신가요?
지금 가입하면 모든 질문의 답변을 볼 수 있어요!