Today I Learned_220915
HTTP
HTTP API 설계 예시
설계할 때 어떤 식으로 URI를 설계하는지?
GET/POST/PUT/DELETE를 어떻게 써야 하는지?
POST/PUT의 주요 특징들
리소스를 식별하는 것(URI) - 리소스를 식별해야지 다른 것을 식별하면 안 된다.
리소스는 행위가 아닌 자원! 행위는 메소드를 사용하면 된다.
회원 관리 시스템
POST 기반 등록 -> 컬렉션
- 회원 목록 /members -> GET
- 멤버에 대한 데이터를 json으로 내려주자
- 회원 수가 너무 많으면 검색 필터를 쿼리 스트링으로 넣어주자
- 정렬 또한 쿼리 스트링으로
- 회원 등록 /members -> POST
- 이 컬렉션에다가 넣으면 된다.
- 회원 조회 /members/{id} -> GET
- 회원 수정 /members/{id} -> PATCH, PUT, POST
- PUT은 기존거를 삭제하고 덮어버린다.
- PATCH : 부분적으로 수정 - 이거를 하는게 좋다
- 웬만해서는 PATCH를 사용하지만, 게시글 수정같은 경우 PUT을 사용하기도 한다 - 완전히 대체하기 때문
- 회원 삭제 /members/{id} -> DELETE
POST를 사용해 신규 자원을 등록할 때의 특징
- 클라이언트는 등록될 리소스의 URI를 알 수 없다.
- /members를 통해 등록했는데, 이 members 리소스가 무엇?
- 신규 리소스를 식별할 수 있는 URI는 클라이언트가 아니라 서버가 만들어준다.
- 서버가 /members를 통해 회원을 생성하고, 100번 리소스란걸 만든다
- 서버가 클라이언트에 응답할 때 리소스의 위치를 응답 메시지로 보내준다
- 서버에서 리소스 URI를 결정하고 만들어 준다.
- 클라이언트가 서버에 요청하는 형태
컬렉션(Collection) 형식
- 서버가 관리하는 리소스 디렉토리
- 서버가 리소스의 URI를 생성하고 관리
- 여기서 컬렉션은 /members 에 해당
파일 관리 시스템
PUT 기반 등록 -> 스토어
- 파일 목록 /files -> GET
- /files 하위에 있는 파일들이 다 나온다
- 파일 조회 /files/{filename} -> GET
- 개별 파일 조회
- 파일 등록 /files/{filename} -> PUT
- 파일 이름은 클라이언트가 파일 이름을 알고 있음
- PUT은 기존걸 지우고 올림
- 파일을 올릴 때는 기존 거를 지우고 올려야 함
- 파일 삭제 /files/{filename} -> DELETE
- 파일 대량 등록 /files -> POST
PUT을 사용해 신규 자원을 등록할 때의 특징
- 클라이언트가 리소스의 URI를 알고 있어야 함
- 클라이언트가 직접 리소스의 URI를 지정. 생성된 URI를 알고 관리를 한다.
- 서버는 오는대로 관리해준다.
스토어(Store) 형식
- 클라이언트가 관리하는 리소스 저장소
- 클라이언트가 리소스의 URI를 알고 관리
- 여기서 스토어는 /files 에 해당
- 스토어 형식보다는 컬렉션 형식을 주로 많이 사용하긴 함
HTML FORM 사용
GET, POST만 지원하나, AJAX같은 기술을 사용해서 해결이 가능하긴 함
GET, POST만 지원하므로 제약이 크다.
- 회원 목록 /members -> GET
- 회원 등록 폼 /members/new -> GET
- 폼을 불러올 때는 GET 사용
- 회원 등록 /members/new, /members -> POST
- 저장을 누를 때 POST로 넘어가야 한다
- GET과 POST의 url을 맞출 수도 있지만, 컬렉션 자원을 관리하는 것 처럼 /members 로 지정해도 된다
- url 1:1 매칭시켜도 되고, 다른 url 사용해도 됨
- 회원 조회 /members/{id} -> GET
- 회원 수정 폼 /members/{id}/edit -> GET
- 폼 자체를 보는 것은 변경이 일어나지 않음
- 폼을 실제로 서버로 보낼 때 변경이 일어남
- 회원 수정 /members/{id}/edit, /members/{id} -> POST
- 회원 삭제 /members/{id}/delete -> POST
- DELETE 메소드를 사용할 수 없으므로 POST 사용해서 처리
- control uri 사용해야 함..
컨트롤 URI(컨트롤러)
- GET/POST만 지원하므로 제약이 있음
- 제약을 해결하기 위해 동사로 된 리소스 경로 사용
- /new, /edit, /delete 등
- 최대한 리소스 개념을 가지고 uri을 설계하되, 여의치 않은 경우 대체제로 컨트롤러 사용
- HTTP 메서드로 해결하기 애매한 경우 사용(HTTP API 포함)
참고하면 좋은 URI 설계 개념
문서
- 단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 row)
- /members/100, /files/star.jpg
컬렉션
- 서버가 관리하는 리소스 디렉터리
- 클라이언트는 요청만 진행
- /members
스토어
- 클라이언트가 관리하는 자원 저장소
- /files
컨트롤러
- 문서, 컬렉션, 스토어로 해결하기 위한 추가 프로세스 실행
- HTTP API에 사용
- /members/{id}/delete
기준 - 리소스로 구분이 가능한지? (예 : 회원이면 member, 회원 관리할거니까 members)
리소스로 나눴으면 각 리소스를 찾을 수 있는 번호 같은 것을 붙여준다 (예 : members/{id})
그래도 해결이 안 되면 컨트롤러 사용
기본적으로 컬렉션/스토어 내에서 해결을 하되, 그래도 힘들면 컨트롤러를 사용하자.
참고 : https://restfulapi.net/resource-naming/