는 서비스와 서비스끼리 통신하기 위해, 즉 요청과 응답을 주고받기 위해 정의된 다양한 종류의 인터페이스이다. ‘다양한 서비스가 만나는 지점’이자 ‘서비스의 동작을 정의한 일종의 약속’이라고도 표현할 수 있을 것 같다. 실제 서비스를 제공하기 위해서는 무수히 많은 소프트웨어 서비스가 맞물려서 운영되어야 하기 때문에, 구체적이고 확장성이 높은 API를 정의하는 것은 매우 중요하다. API는 어떤 방식으로 동작할까? API는 클라이언트와 서버 사이에서 요청과 응답을 통해 리소스를 주고받는 방식으로 동작한다. API를 구성하는 요소들은 아래와 같다. 자원(resource) ‘이 리소스를 어떻게 명확하게 표현할 수 있을지?‘가 바로 API가 풀어내야 할 과제가 된다. 여기서 리소스는 DB에 저장된 데이터 자체가 아닌, 데이터의 상태를 클라이언트가 요청한 방식에 맞추어 표현하여 전달한 응답이다. 리소스는 JSON 데이터일수도, 이미지일수도 또는 어떠한 문서일수도 있다. 동작(method) 또…

기능을 추가하며 모델을 변경해야 할 일이 새겼다. 테이블을 수정하고 migration을 적용하면서 dependency 오류부터 relationExists 오류까지 아주 난항을 겪었다. 사실 토이프로젝트에서는 migration이 꼬이면 그냥 전부 밀어버리고 다시 적용하면 그만이었다. 하지만 실제로 배포되고 데이터가 담겨 있는 DB의 테이블을 수정하는 경우에는 이런 1차원적인 방식으로 접근할 수는 없었다. 다소 긴 삽질의 과정을 경험하며, 내가 migration에 대하여 정확히 이해를 하지 못하고 있음을 깨달았다. Migration이란? 일종의 database version control log라고 이해하면 될 것 같다. 명령어를 수행하면 각 app의 모델에 대한 변경사항을 기록한 python script가 자동으로 생성되고 명령어를 수행하면 db에 변경사항을 반영할 수 있다. 이 migration script는 형식으로 네이밍되며, 모델 간의 관계(생성 순서, 참조 방향 등)를…

장고는 하나의 프로젝트 내에 여러 개의 app이 존재하는 구조이다. 명령으로 app을 생성한 뒤, 에 생성한 app을 등록하여 손쉽게 관리할 수 있다. 아래의 이미지는 명령어를 통해 app을 생성했을 떄의 기본 구조이다. 루트 디렉토리에 장고 서버를 구동하기 위해 필요한 파일이 존재하고, 생성된 app 디렉토리 내부에 , , , 과 같은 파일이 생성된다. 새로운 사이드 프로젝트를 사용하면서도 이러한 디렉토리 구조를 그대로 사용하고 있었는데, 프로젝트가 정리되어 있지 않은 느낌이 있다는 피드백을 들었다. 하지만 과 를 개발용/운영용 환경으로 분리하는 것 외에 프로젝트 구조를 유연하게 설정할 수 있는 방법이 어떤 것이 있을지 감히 잡히지가 않았다. “장고는 프로젝트를 app 단위로 나누어 관리하니까, app을 더 쪼개야 하는건가? 아니면 합쳐서 단순화해야 하는걸까?”와 같은 고민을 하다가.. app을 생성하고 디렉토리가 많아지면서 프로젝트 구조가 난잡하다라는 생각이 종종 들었으니,…