작성자 없음
작성자 정보가 삭제된 글입니다.
작성
·
387
·
수정됨
0
안녕하세요 먼저 좋은 강의 감사합니다
강의 수강중 궁금한 부분이 생겼는데 검색해도 잘 안나와서 질문 드립니다
API 장점 중
내부 프로세스가 수정되었을 때 API를 매번 수정하는 것이 아닌 API가 수정이 안되게 만들 수 있습니다. 이를 통해 내부 DB, 서버의 로직이 변경되어도 매번 사용자가 앱을 업데이트 하는 일은 줄어들 수 있습니다. 라는 내용이 있는데
내부 프로세스는 수정되지만 API를 수정이 안되게 만들어서 업데이트를 하지 않아도 되게 만든다는 말 같은데 결국 내부 프로세스는 수정이 된 것 아닌가요?
로직은 바뀌었는데 API가 수정이 안되게 만들 수 있다는 말이 잘 이해가 되지 않습니다 ..
답변 1
0
안녕하세요 능이 개발자님 ㅎㅎ
내부 프로세스는 수정되지만 API를 수정이 안되게 만들어서 업데이트를 하지 않아도 되게 만든다는 말 같은데 결국 내부 프로세스는 수정이 된 것 아닌가요?
로직은 바뀌었는데 API가 수정이 안되게 만들 수 있다는 말이 잘 이해가 되지 않습니다 ..
>>
자, 우리가 어떤 내부 코드를 업데이트했습니다. 그렇다고 해서 무조건 앱을 업데이트하게 만들어야 할까요?
서비스가 실제 사용자들에게 보여지기 까지 간단하게 이 3가지의 과정을 거쳐서 배포가 됩니다. (테스트 등등의 과정은 생략하겠습니다. )
개발 > 릴리스 > 배포
여기서 릴리스란 프로덕션 레벨의 코드로 머지를 한것(코드수정한 것을 합친 것)이라고 이해하시면 됩니다.
릴리스를 했다고 무조건 배포를 하지는 않습니다.
즉 수정과 배포는 다른 것입니다.
다시말해 내부코드가 수정되었다고 해서 무조건 해당 반영된 값을 바로 배포하지는 않습니다.
업데이트가 되면 앱을 실행했을 때 이런식으로 사용자가 "귀찮게" 업데이트를 해야 하는 상황으로 갈 수 있기 때문이죠.
API도 이와 동일하게 생각하시면 됩니다.
API라는 중간 단계가 있기 때문에 업데이트가 바로 반영되지 않습니다.
만약 내부 로직이 수정되었다고 해서 바로 서비스가 바뀔 수도 있겠죠?
근데 여기서 API라는 인터페이스 계층을 하나 둠으로써
내부로직이 수정이 되어도 API는 그대로인채 내버려 둘 수 있습니다.
예를 들어
API v1을 쓰고 있는 사람이 있습니다. API 내부 로직이 변경되었다고 해서
갑자기 api/hongchul 이라고 요청해야 하는 것을 api/chul 이런식으로 요청하라고 하면 해당 사람이 만든 서비스 등의 로직을 수정해야겠죠?
그러나 수정을 해도 해당 API는 수정안되게 만들면 그러한 상황을 피할 수 있습니다.
제가 그림을 그려봤는데요. 위에 부분은 만약 API가 없을 때 입니다. 수정된 것이 바로 반영되지만, 아랫부분은 API라는 계층이 있기 때문에 코드 수정부분이 바로 사용자에게 반영되지 않게 만들 수 있습니다.
또 질문 있으시면 언제든지 질문 부탁드립니다.
좋은 수강평과 별점 5점은 제가 큰 힘이 됩니다. :)
감사합니다.
강사 큰돌 올림.