REST URI 설계

REST?

REpresentational State Transfer의 약자
REST의 기본 원칙을 지키면 RESTful하다고 할 수 있지..

• client-servr
• Stateless
• Cacheable
• Uniform interface
• Layered system
• Code on demand (optional)

REST는 HTTP가 아니다

자원은 명사로 표현

RESTful URI는 자원(resource)을 명사로 표현한다

document

• 단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 row)
• 예: users/{id}, /users/admin

collection

• 서버가 관리(server-managed)하는 리소스 디렉터리
• 서버가 리소스의 URI를 생성하고 관리
• 예: /members, /users/{id}/accounts

store

• 클라이언트가 관리(client-managed)하는 리소스 저장소
• 저장소는 새로운 URI를 생성하는게 아니라 저장된 각각의 자원들은 URI를 가지고 있다
• URI는 클라이언트에 의해 선택된다 (클라이언트가 저장소에 저장할 때)
• 예: users/{id}/playlist, files/{id}

controller

• 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행
• 동사를 직접 사용
• 예: /members/{id}/delete, users/{id}/cart/checkout

일관성

일관된 리소스 명명 규칙과 URI형식을 사용해야 한다.

• 슬래시(/)를 사용해 계층 관계를 나타낸다 예: /users/{id}/oders/{orderId}
• 경로 마지막에 의미없는 슬래시를 사용하지 마라
• 하이픈(-)을 사용해 URI의 가독성을 높이자 (카멜케이스보다 하이픈을 지향)
• 밑줄(_)을 사용자미 마라! (되도록 하이픈을 사용)
• 소문자를 사용해라
• 파일 확장자 사용을 지양해라 (파일 확장자를 사용하고 싶다면 Content-Type헤더를 통해 전달하자)
• CRUD함수 이름을 사용하지 말 것 (HTTP METHOD를 사용해 나타내라)
• 필터링은 query string을 이용해라

클라이언트에서 서버로 데이터를 전송할 때

• 쿼리 파라미터 (쿼리 스트링)를 통해 데이터 전송
  • GET메서드
  • 주로 정렬 필터나 검색어에 사용
• 메시지 바디를 통한 데이터 전송
  • POST PUT PATCH
  • 리소스 변경에 사용
• 정적 데이터를 조회할 때
  • GET
  • 정적 데이터는 일반적으로 쿼리 파라미터 없이 URI로 단순하게 조회한다
• 동적 데이터를 조회할 때
  • GET
  • 주로 검색, 게시판 목록의 정렬 필터
  • 쿼리 파라미터를 사용

---

읽어보기