Django REST Framework와 API View 활용하기
⚒️ refactoring: API URI를 복수 명사로 바꾸었다!
url : api/posts/
GET
url : api/posts/<int:pk>/
GET
url : api/posts/
POST
url : api/posts/<int:pk>/
PUT
url : api/posts/<int:pk>/
DELETE
장점: 구현이 간단함, 읽기 편함, 직관적인 코드, 데코레이터 사용이 간단함
단점: 코드를 확장하거나 재사용하기 어려움, 조건문으로 HTTP 메소드 구분함
장점: 코드를 확장하거나 재사용하기 쉬움, 다중 상속 같은 객체지향 기술을 사용할 수 있음, 분리된 메소드로 HTTP 메소드 구분
단점: 읽기 힘듦, 부모 클래스/mixin에 코드가 숨어있음
👉 무엇이 더 좋고 나쁘고를 따지기보다는 상황에 맞게 사용하는 게 좋다.
예를 들어, 리스트 뷰를 구현할 때엔 ListView를 상속받고 어트리뷰트를 오버라이드하면 된다.
반면에 여러 폼들을 한꺼번에 다뤄야 하는 복잡한 연산을 할 땐 함수 기반 클래스를 사용하면 된다.
100번대 코드는 계속 요청을 보내도 된다는 식의 정보성을 띄고 있는 상태를 의미한다.
200번대 코드는 클라이언트가 요청한 동작을 수신했고 승낙했으며 성공적으로 처리했음을 가리킨다.
300번대 코드는 요청을 완료하기 위해서 리다이렉션이 이루어져야 한다는 의미이다.
단축 URL 서비스의 경우 접속 시 301이나 302 코드를 보내고, 헤더의 location에 리다이렉션할 실제 URL을 적어 보낸다.
400번대의 코드는 클라이언트가 서버에게 보낸 요청이 잘못된 경우를 의미한다.
500번대의 코드는 올바른 요청에 대해 서버가 응답할 수 없다는 의미이다.
가장 끔찍한 코드이다...
Postman을 이용해서 API 테스트를 하는데 계속 이상한 오류가 나서 일단 당황하고 구글에 여기저기 찾아보았는데, 결국엔 request url 끝에 /를 안 붙여서가 원인인 케이스가 2번 정도 났었습니다...
항상 그렇지만 오류가 나면 오타를 1순위로 의심해야한다는 것을 다시 깨닫게 되었습니다 🥲