HTTP API - 컬렉션
- POST 기반 등록
- 예) 회원 관리 API 제공
HTTP API - 스토어
- PUT 기반 등록
- 예) 정적 컨텐츠 관리, 원격 파일 관리
HTML FORM 사용
- 웹 페이지 회원 관리
- GET, POST만 지원
회원 관리 시스템
API 설계 - POST 기반 등록
리소스(회원)를 식별해라!
- 회원 목록 /members -> GET
- 회원 등록 /members -> POST
- 회원 조회 /members/{id} -> GET
- 회원 수정 /members/{id} -> PATCH, PUT, POST
- 회원 삭제 /members/{id} -> DELETE
Tip) PUT은 기존 것을 삭제하고 완전히 덮어쓰이는 개념이라 잘 사용하지 않는데, 게시글 수정 같은 경우에는 사용할 수 있다. 게시글 수정은 부분 수정이 아닌 글 자체를 덮어써도 되기 때문!
POST - 신규 자원 등록 특징
- 클라이언트는 등록될 리소스의 URI를 모른다.
- 회원 등록 /members -> POST
- POST /members
- ⭐ 서버가 새로 등록될 리소스 URI를 생성해준다.
- HTTP/1.1 201 Created
- Location: /members/100
- 위를 컬렉션(Collection)이라고 한다.
- 서버가 관리하는 리소스 디렉토리
- 서버가 리소스의 URI를 생성하고 관리
- 여기서 컬렉션은 /members
파일 관리 시스템
API 설계 - PUT 기반 등록
- 파일 목록 /files -> GET
- 파일 조회 /files/{filename} -> GET
- 파일 등록 /files/{filename} -> PUT
- 파일 삭제 /files/{filename} -> DELETE
- 파일 대량 등록 /files -> POST
파일 등록은 PUT이다.
파일을 등록하려면 기존 파일을 지우고 그 위에 올려야하기 때문이다.
PUT - 신규 자원 등록 특징
- 클라이언트가 리소스 URI를 알고 있어야 한다.
- 파일 등록 /files/{filename} -> PUT
- PUT /files/star.jpg
- 클라이언트가 직접 리소스의 URI를 지정한다.
- 위를 스토어(Store)라고 한다.
- 클라이언트가 관리하는 리소스 저장소
- 클라이언트가 리소스의 URI를 알고 관리
- 여기서 스토어는 /files
HTML FORM 사용
- HTML FORM은 GET, POST만 지원
- AJAX 같은 기술을 사용해서 해결 가능 -> 회원 API 참고
- 여기서는 순수 HTML, HTML FORM 이야기
- 따라서 GET, POST만 지원하므로 제약이 있음
- 컨트롤 URI
- 제약을 해결하기 위해 동사로 된 리소스 경로 사용
- POST의 /new, /edit, /delete가 컨트롤 URI
- HTTP 메서드로 해결하기 애매한 경우 사용 (HTTP API 포함)
- 최대한 리소스의 개념을 사용하여 URI를 설계하고, 애매하거나 잘 되지 않을 때 컨트롤 URI를 사용하기
회원 관련 HTML FORM 사용해보기
- 회원 목록 /members -> GET
- 회원 등록 폼 /members/new -> GET
- 회원 등록 /members/new, /members -> POST
- 회원 조회 /members/{id} -> GET
- 회원 수정 폼 /members/{id}/edit -> GET
- 회원 수정 /members/{id}/edit, /members/{id} -> POST
- 회원 삭제 /members/{id}/delete -> POST
정리
참고하면 좋은 URI 설계 개념
- 문서(document)
- 단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 row)
- 예) /members/100, /files/star.jpg
- 컬렉션(collection)
- 서버가 관리하는 리소스 디렉터리
- 서버가 리소스의 URI를 생성하고 관리
- 예) /members
- 스토어(store)
- 클라이언트가 관리하는 자원 저장소
- 클라이언트가 리소스의 URI를 알고 관리
- 예) /files
- 컨트롤러(controller), 컨트롤 URI
- 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행
- 동사를 직접 사용
- 예) /members/{id}/delete
추가 공부
회원 수정 /members/{id}/edit -> POST 라는 URI를, /members/edit/{id} -> POST 로 설계하여도 괜찮을까?
-> 잘못된 것은 아니지만, 특정 리소스(member)를 표현할 때 리소스가 속한 카테고리(/members) 뒤에 리소스 식별자(/{id})를 위치시키는 것이 관례이다.
HTTP API를 기반으로 한 것이 REST API인가?
-> HTTP API와 REST API는 거의 같은 의미로 사용되지만, 엄밀히 말하면 다르다.
HTTP API는 HTTP를 사용해서 서로 정해둔 스펙으로 데이터를 주고 받으며 통신하는 것이라고 할 수 있다. 그래서 상당히 넓은 의미로 사용된다.
반면에 REST API는 HTTP API에 여러가지 제약 조건이 추가된다.
REST는 다음 4가지 제약조건을 만족해야 한다.
1. 자원의 식별
2. 메시지를 통한 리소스 조작
3. 자기서술적 메세지
4. 애플리케이션의 상태에 대한 엔진으로서 하이퍼미디어
대표적으로 구현하기 어려운 부분은 마지막 4번이다. 이것은 HTML처럼 하이퍼링크가 추가되어서 다음에 어떤 API를 호출해야 하는지를 해당 링크를 통해 받을 수 있어야 한다.
이러한 부분을 완벽하게 지키면서 개발하는 것을 RESTful API라고 하는데, 실무에서 이런 방법으로 개발하는 것은 현실적으로 어렵고 또 추가 개발 비용대비 효과가 있는 것도 아니다.
그런데 이미 많은 사람들이 해당 조건을 지키지 않아도 REST API라고 하기 때문에, HTTP API나 REST API를 거의 같은 의미로 사용하고 있다.
