ReST §
- 간단하게만 말하면 URI 로 정보의 자원을 표현하고 (명사)
- HTTP Method 로 자원의 처리법을 표현 (동사) 한다
- 그리고 사람이 읽기 편하도록 설계해야 한다
단점 §
- 일단 명확한 표준이 없어서 좀 난해하고 사람마다 다를 수 있음
- 멱동성을 보장하지 않기 때문에 분산환경에 적합하지 않음? → 뭔소리임
URI 구성 §
- 일단
/ 는 계층관계를 표현하는 데에 사용된다 → / 를 사용할 수록 더 구체적인 자원을 표현한다고 생각하면 될듯
- 위에서도 말했듯이 URI 에는 자원이 들어가야지 행위(처리법) 에 대한 언급이 들어가서는 안된다
- URI 의 마지막에는
/ 를 사용하지 않는다
- URI 에는
_ 을 사용하지 않는다
- 소문자를 사용한다
- 파일 확장자는 포함하지 않는다 → Accept header 를 사용하는 것이 바람직하다
관계 표현하기 §
- ‘has’ 관계의 표현
- 몰랐는데 이런식으로 한다더라
- 어떤 유저가 갖고 있는 디바이스들을 조회할때
GET: /users/${USER_ID}/devices
- Document, Collection
- Document: 뭐 그냥 단일 객체라고 생각해도 된다. 사람 한명, 음료수 하나 등 → 당연히 단수명사로 표현하는게 보기 좋다
- Collection: 이건 Document 들의 모임이라고 생각하면 된다. 복수명사로 표기하는게 읽기 좋다
- 이걸 이용해서
(/${COLLECTION}/${DOCUMENT})* 형식으로 표현할 수 있다
- 예를 들면 축구선수 13을 표현할때
GET: /sports/soccer/players/13 라고 표현하면 보기 좋제?