기본 원칙
REST API를 설계할 때 아래의 두가지가 가장 중요하다.
- URI는 정보의 자원을 표현 해야한다.
- 자원에 대한 행위는 HTTP Method로 표현한다.
블로그에 게시글을 수정할 때의 예시로 들어보자
URI는 정보의 자원을 표현해야 한다.
좋지 않은 예
GET /boards/1/posts/update/1URI는 자원을 표현 해야한다. 따라서 update같은 행동에 대한 정보가 포함되선 안된다.
자원에 대한 행위는 HTTP Method로 표현한다.
앞의 내용과 이어져, update같은 행동에 대한 정보는 HTTP Method로 표현되어야 한다는 뜻이다.
따라서 요청은 아래와 같이 수정되어야 한다.
PUT /boards/1/posts/1
PATCH /boards/1/posts/1[참고하기] 상황에 맞는 HTTP Method
| Method | 역할 |
| GET | 리소스를 조회 한다. |
| POST | 리소스를 생성한다. |
| PUT | 리소스를 수정한다. |
| PATCH | 리소스의 일부를 수정한다 |
| DELETE | 리소스를 삭제한다. |
| OPTIONS | CORS |
| HEAD | 헤더만 가져온다. |
REST API를 설계하고 사용하면 위 Method에 대해 알고 있어야 한다.
URI 설계할 때 주의해야 할 점
1. 슬래시(/)는 계층관계를 나타내는데 사용하라.
앞의 예제와 같이, URI를 보고 1번 boards 하위의 1번 Post임을 식별 할 수 있어야 한다.
PUT /boards/1/posts/1또한 URI는 리소스의 유일한 식별자로 사용되기 때문에 마지막 문자로 슬래시(/)를 포함하지 않는다.
2.URI 가독성을 위해 긴 경로는 하이픈(-) 을 사용하라.
자원을 표현이 길면 하이픈을 사용해 가독성을 높일 수 있다. 생각보다 카멜케이스가 보기 힘들다.
3. 언더바(_)는 사용하지 않는다.
경로에 언더바를 사용하게 되는 경우에는 보기 어렵고, 밑줄쳐졌을 때 문자가 가려져 가독성에 좋지 않다.
4. 가능하면 소문자로 작성하라.
URI는 대소문자에 따라 다른 리소스로 인식이 된다. 통일성을 위해 소문자로 작성하는 것이 좋다.
5. 파일 확장자는 URI에 포함시키지 않는다.
REST API는 body의 포멧을 URI가 아닌 Accept 헤더를 사용하여 받도록 되어있다.
리소스 간의 관계를 표현하기
URI는
/리소스명/ID/하위관계의 다른 리소스
ex) /boards/1/posts/1
의 규칙으로 작성하며, 리소스명은 복수명사로 작성하는 것이 좋다.
댓글