URI 설계하기

URI 설계하기:

URI(Uniform Resource Identifier)란 영어 약자를 풀어보면 '균등한 리소스 식별자'정도로 할 수 있습니다. 말그대로 인터넷의 어떠한 리소스를 식별하기 위해서 만들어진 것이다.

1. 소문자를 사용하자(최소한 대소문자를 구분한다는 사실을 알고있자)

2. 하이픈(-, hyphen)을 사용하자

경로(path)에 공백(띄어쓰기)가 들어갈땐 경우에따라 띄어쓰기 대신 %20이 쓰일때가 있습니다. 이런건 보기에 별로 좋지 않기때문에 많은 사람들이 밑줄(_, underscore) 또는 하이픈(-, hyphen)을 사용하여 공백을 대체합니다. 여기서 권장하는건 하이픈만 사용하자 입니다. 보통 밑줄은 링크가 걸린부분에 표시되는데 그것과 중복되면 리소스로써의 밑줄은 가려질 수도있기때문에 하이픈을 사용하자.

3. 확장자를 사용하지 말자

기존의 많은 URI들이 확장자를 포함하고 있습니다. 하지만 REST API를 설계할때에는 확장자는 사용하지 않는게 좋겠습니다. 확장자를 사용하지 않으면 리소스가 더 유연해집니다. 어째든 확장자를 사용하지 않는다면 기존에 REST API를 접해보지 않는 사람들은 이런 의문을 갖을 수 있습니다? 결론적으로 Accept header를 사용해야 합니다. 예를들어 내용이 Hello,World인 파일이 있습니다. 서버를 기존방식대로 설계한다면 해당 파일은 http://remotty.com/hello.txt와 같이 요청하여 응답받을 것입니다. 기존의 방식은 분명하게 파일의 형태가 txt로 고정되어있습니다. csv 형태로도 제공하려면 http://remotty.com/hello.csv URI도 준비해야 할것이고, 서버엔 hello.txt와 hello.csv 두개의 파일이 존재 하게 될것입니다. http://remotty.com/hello.txt와 http://remotty.com/hello.csv는 분명하게 다른 리소스를 식별하는 URI이지만, 실제론 하나의 리소스를 가르키고 있습니다. 이것은 비 효율적입니다. 리소스가 한개라면 URI도 한개여야합니다.

4. REST API로 구현했을땐

GET /hello HTTP/1.1

Host: remotty.com

Accept: text/plain

또는

GET /hello HTTP/1.1

Host: remotty.com

Accept: text/csv

Accept를 좀더 적극적으로 활용한다면 이렇게도 가능합니다.

GET /hello HTTP/1.1

Host: remotty.com

Accept: text/csv,text/html;q=0.5,application/xml;q=0.6,text/plain;q=0.9,applicat

5. CRUD는 URI에 사용하면 안된다

과거에 GET, POST만 사용하였을땐 CRUD를 URI에 표시해주어야 했습니다.

GET /posts/13/delete HTTP/1.1

POST /posts/write HTTP/1.1

GET /delete?id=55 HTTP/1.1