[웹 개발자를 위한 웹을 지탱하는 기술] - URI 설계

김성혁·2022년 3월 27일
0

좋은 URI란 무엇인가?

👨🏻‍💻 쿨(Cool)한 URI는 변하지 않는다

  • 좋은 URI를 Cool URI라 부름.
    • Cool URIs don’t change

👨🏻‍💻 좀처럼 변하지 않는 URI를 만들기 위해서는


프로그래밍 언어에 의존적인 확장자와 경로를 포함하지 않는다.

📝 http://example.com/cgi-bin/login.pl
📝 http://example.com/servlet/LoginServlet
  • URI가 잘 변경되지 않도록 하기 위해서는 프로그래밍 언어에 의존적인 부분을 배제해야 한다.

메서드명과 세션 ID를 포함하지 않는다.

📝 http:/ /example.com/Login.do?action =showPage
📝 http://example.com/home.jsp?jsessionid=12345678

URI는 리소스를 표현하는 명사로 한다.

  • URI는 리소스의 이름이기 때문에 명사여야 합니다.
    • URI와 HTTP 메서드의 관계는 명사와 동사의 관계와 같습니다. 따라서 URI는 전체적으로 명사가 되도록 설계해야 합니다.
📝 http://example.com/sample/people/show/123
  • 최근의 프레임워크라면 ,구현에 의존적인 URI는 디폴트로 만들 수 없도록 되어 있습니다.
📝 http://example.com/sample/people/123

URI 설계지침

  • URI에 프로그래밍 언어에 의존적인 확장자를 이용하지 않는다.
  • URI에 구현에 의존적인 경로명을 이용하지 않는다.
  • URI에 프로그래밍 언어의 메서드명을 이용하지 않는다.
  • URI에 세션 ID를 포함하지 않는다.
  • URI는 해당 리소스를 표현하는 명사이다.

👨🏻‍💻 URI 사용성

  • 심플한 URI의 또 하나의 장점은 사용성 향상
    • 복잡한 URI 📝 http://example/servlet/LoginServlet
    • 심플한 URI 📝 http://example.com/login
    • 기억하기 쉽고, 개발자가 아닌 보통 사람들도 사용하기 쉽도록 설계해야 한다.

👨🏻‍💻 URI를 변경하고 싶을 때

  • 현재 운용중인 시스템의 URI를 안이하게 변경해선 안 되고,

  • 가능한 한 Redirect 하도록 한다.

    • Redirect란 오래된 URI를 새로운 URI로 전송하는 HTTP의 기능
  • 변경 전

    📝 http://example.com/old
  • 변경 후

    📝 http://example.com/new
  • Redirect되어 있는 오래된 URI를 클라이언트가 취득하면 다음의 응답을 반환 📝 HTTP/1.1 301 Moved Permanently Location: http://example.com/new

👨🏻‍💻 URI 설계의 테크닉

확장자로 표현을 지정하는 방법인 매트릭스 URI

확장자로 표현을 지정한다.

  • 나쁜 것은 구현에 의존하는 확장자이다.
  • 구현에 의존하지 않는 확장자는 좋은 측면을 가지는 경우가 있다.
    • 프레스 릴리스를 웹에 공개하는 경우
      • 전 세계를 상대로 활동하는 기업에서는 프레스 릴리스를 복수의 언어로 기술
      • 그 예. 프레스 릴리스 리소스는 하나이고, 그 표현이 영어이거나 한국어인 경우
      • HTTP에는 콘텐츠 네고시에이션(Content Negotiation)이라는 기능이 존재
      • Accept-Language 헤더에서 클라이언트가 희망하는 언어를 지정
      • 요청의 조건에 따라 요청에 해당하는 언어 프레스 릴리스를 응답으로 돌려줌.
      • 콘텐츠 네고시에이션의 경우 브라우저 설정을 변경해야 하지만 다음과 같은 URI를 사용함으로써 다른 언어판 프레스 릴리스에 접근 가능
      • http://example/2010/05/01/press.ko (프레스 릴리스 한국어판)
      • http://example/2010/05/01/press.en (프레스 릴리스 영어판)
      • 하나의 리소스가 복수의 표현을 가질 때, 각 리소스의 표현을 나타내는 확장자를 사용하는 것은 나쁜 일이 아니다.
      • 예를 들어 하나의 리소스를 HTML과 텍스트, JSON으로 표현할 수 있는 경우

매트릭스 URI

  • URI는 슬래시(/)를 사용해 계층을 표현
  • 여러 파라미터의 조합으로 표현하는 리소스에는 매트릭스 URI를 사용
    - 각각의 파라미터를 세미콜론(;)으로 구분해 리소스를 표현
    - 위도와 경도의 표현
    - http://example.com/map/lat=35.705471;Ing=139.751898
    - 세미콜론은 파라미터의 순서가 의미를 가지지 않는 경우 사용
    - 콤마는 파라미터의 순서가 의미를 가지는 경우 사용
    - http://example.com/map/35.705471, 139.751898

👨🏻‍💻 URI의 불투명성

  • 심플한 URI는 가독성이 높기 때문에 사용자가 URI의 구조를 추측하기 쉬워짐.
  • 클라이언트에서는 서버가 제공하는 URI를 그대로 사용하기 때문에 URI의 내부구조를 상상해 조작하거나, 클라이언트 쪽에서 URI를 구축해서는 안 됩니다.
    - 서버 쪽에서 URI의 구조를 변경하는 순간 시스템이 동작하지 않게 되는 밀결합 상태가 되기 때문

URI를 클라이언트 쪽에서 구성하거나 확장자로 리소스의 내용을 추단하거나 할 수 없는 특성을 ‘URI는 클라이언트에 있어 불투명하다'라고 한다.


👨🏻‍💻 URI를 강하게 인식하기

  • URI는 리소스의 이름이다.
  • URI는 수명이 길다.
  • URI는 브라우저가 어드레스 란에 표시한다.
  • 이런 관점에서 URI는 웹 서비스와 웹 API의 설계에 있어서 가장 중요해야 할 부분

0개의 댓글