inflearn logo
강의

강의

N
챌린지

챌린지

멘토링

멘토링

N
클립

클립

로드맵

로드맵

지식공유

모든 개발자를 위한 HTTP 웹 기본 지식

URI naming 문의드려요.

192

아리마

작성한 질문수 75

0

영한님, 안녕하세요.

URI naming 관련해서 2가지 문의를 남기고 갈께요. 항상 바쁘시지만 고견을 구합니다.

1) API 버전

    - 영한님, 수많은 강의에서 보면 API 에는 주로 V1, V2 같은 버전을 기록하시는 것 같던데
       이번 강의에서는 버전에 대한 말씀은 없으시더라고요. 
       보통 버전을 URI 에 포함시키는게 좋은 지, 만약 포함시킨다면 버전의 위치는 어디가 가장 적합한지 알고 싶습니다.

2) 복잡한 쿼리 조회성 API naming

     - 현업에서는 검색조건이 다양하게 있고 결과도 UI Grid 에 다양한 컬럼이 있는 표 화면을 활용하는 케이스가 많은데요.
        (보통 API 에서 다수의 테이블을 조인하는 쿼리를 실행해서 출력하는)
        이런 API는 사실 Main Resource 를 정하기 어려운 경우가 상당히 있는 것 같습니다.
        이런 복잡한 쿼리를 통해 화면에 목록성 데이터를 출력하는 Get API 는 네이밍을 어떻게 잡는 게 좋을까요?

network

답변 1

0

김영한

안녕하세요. 아리마님

1. 여러가지 방안이 있는데요. 만약 버전이 필요하다면 저는 URL에 버전을 적용하는 것을 선호합니다. HTTP 헤더에 버전을 사용할 수도 있는데, 예를 들어서 HTTP 헤더에 넣게되면 이것을 누락했을 때 최신 버전을 사용하는 식으로 사용하는 경우가 있더라구요. 그런데 이렇게 되면, 향후 새로운 버전이 나왔을 때 과거 스펙이 다 깨지면서 문제가 발생할 수 있습니다. 그래서 가급적 명확하게 URL에 버전을 명시하는 것을 선호합니다. 그리고 모니터링하거나 이럴 때도 URL에 버전이 있으면 더 편리하더라구요. 그런데 이 부분은 다들 생각이 다를 것 같아서 참고만 해주세요.

추가로 실무에서는 버전 같은 것을 실수로라도 누락하지 않게 강제하는 것이 장애를 덜 발생하게 되더라구요. 그리고 필드가 추가되는 것 같은 작은 작은 변화에는 가급적 버전을 올리지 않습니다. 대신 이 API는 향후 필드가 추가될 수 있으니 사용하지 않는 필드는 무시해달라고 스펙에 명확히 명시하고 공유해야 합니다.

2. 이런 경우에는 URI Naming이 잘 맞지 않습니다. 그냥 그 API에 맞는 별도의 이름을 주는 것이 좋다 생각합니다.

감사합니다^^

캐시 관련 질문입니다.

0

634

1

ETag 질문입니다.

0

741

1

캐시의 설정 주체

0

542

1

영속쿠키 질문입니다.

0

518

1

협상(accept-language)

0

697

1

에러 코드의 구현 주체

0

448

1

웹서버가 구현?

0

605

1

필수헤더?

1

568

1

Host와 Port

0

785

1

다른 도메인이 같은 포트를 사용하는 경우

0

1268

1

표준 헤더와 임의 헤더

0

540

1

POST 등록 후 Location 헤더

0

577

1

프로세스의 상태가 변경되는 경우에 Post 사용

1

1819

1

지속연결에 대해서.

0

700

1

제가 아는 쿼리 파라미터 개념이 맞는지 확인 부탁드립니다.

0

602

1

캐시 내용중 no cache 일때

0

368

1

DNS 서버 관련 질문

1

756

1

캐시로 저장된 파일의 유효기간은 얼마나 되나요?

0

674

1

웹브라우저 요청흐름 질문입니다.

0

853

1

캐시 무효화 질문드립니다

0

567

1

리다이렉트와 리다이렉션 차이?

0

2650

1

쿠키 및 세션 관련 질문드립니다

0

595

1

HTTP 메서드 ( HTTP 메서드의 속성 파트 ) 강의의 멱등 내용에 대하여 질문드립니다.

0

1654

1

header 나 gzip으로 데이터 보낼떄 데이터는 base64로 인코딩되서 가는 건가요?

0

486

1