사람

기업

게시물

REST API, URI 작명 어떻게 하지...? 마이크로 서비스 아키텍쳐(MSA)가 유행하면서 자연스럽게 서비스간 통신(커뮤니케이션)을 생각하게 되고 동기화가 크게 영향이 없다면 1순위로 생각하게 되는 건 다름 아닌 HTTP 기반의 API 일것이다. HTTP만 사용하면 REST API 라고 생각하는 개발자들도 종종 발견되는데, REST API 는 철저히 약속의 영역이다. 규칙이 존재한다는 뜻이다. 이 글에서는 REST API에서 명확게 정해지지 않아서 논쟁의 여지가 있는 URI에 대해서 이야기 해보려 한다. 우선 한줄 요약은 'dash-case' 로 작성해야 한다는 것이다. 작명 컨벤션 다양한 것들이 있다. - lowerCamelCase - UpperCamelCase - snake_case - dash-case 카멜 케이스는 자바 진영에서 많이 사용되고 스네이크 케이스는 데이터베이스를 기반으로 하는 몇몇 서버사이드 언어(PHP 등)들과 몇몇 스크립트 언어(python, 루비 등)가 사용하고 있다. 필자는 변수명에서 사용되지 않는 데시 케이스를 URI 작명으로 사용하자고 주장하는 이유는 다음과 같다. 첫번째, 일기 쉽다. 우리는 띄어쓰기를 사용하는 이유는 가독성이 좋기 때문이다. 위에 언급한 컨벤션을 가독성의 순서로 나열하면 dash case > snake case >> ... >> camel case 이다. 여러분이 자바 개발자라면 카멜 케이스는 가독성이 좋다고 주장할 수도 있다. 하지만 비개발자들 중에 파일명을 카멜케이스를 쓰는 사람은 거의 없을 것이다. 대부분 스네이크 케이스 혹은 데시 케이스다. 압도적으로 파일명은 데시케이스가 많다. 카멜케이스를 사용하는 개발자들도 제약사항이 없는 작명(프로젝트명, 문서)에서는 데시 케이스를 사용하는 경우가 종종 보인다. 데시 케이스는 본능적/학습적으로 가장 읽기 쉬운 케이스란 것임을 알 수 있다. 다음의 카멜케이스를 쉽게 읽기 어렵다. - ThisIsIllusion - ThisisIlilily 두번째, 스네이크 케이스는 혼선의 여지가 있다. URI 는 HTML에서 링크일 경우에 파란색 밑줄로 표현(스타일링)된다. 몇몇 문서 편집기도 이러한 규칙을 따른다. 그렇기 때문에 URI에는 밑줄을 사용 하면 혼선이 발생한다. API 스펙 문서에 URI가 있고 그것이 파란색 밑줄로 스타일링 되어있다면 실제 밑줄이라서 그런 것인지, 스타일링 때문에 그렇게 보이는지 알수 없게 된다. 세번째, REST API는 개발자들만 사용하는 것이 아니다. REST API를 json 형태를 리턴하는 API라고 오해하는 개발자들이 종종있다. 하지만 REST API는 다양한 표현을 전제한다. json, xml, html, csv 등등 다양한 표현 방식을 전제하는 API다. 일반 사용자들도 HTML 형식의 요청을 브라우저 주소창에 입력하여 직접 들어올 수도 있다. 그들은 앞서 언급한 것처럼 카멜 케이스에 배경지식이 전혀 없는 그룹일 가능성이 높다. REST API는 기본적으로 소통을 효율적으로 하기 위함인데 개발자의 전유물 처럼 사용하면 그것이 오른 방향인지 한번쯤 생각해봐야 할 것이다. 네번째 , URI 스키마와 호스트를 제외하고는 대소문자를 구분한다. 개발자들은 모든 시스템이 대소문자를 구별할 것이라고 착각한다. 하지만 그렇지 못한 시스템들도 존재한다. 혼선의 여지가 분명히 존재한다는 것이다. 다음의 URI를 살펴보자 - http://rest.api/thisIsMyPost - http://rest.api/thisismypost URI 스펙에서는 두 URI 값은 다른 것이라고 규정할 수 있다. 하지만 어떤 시스템에서는 두개의 차이를 구별 불가능 할 수 있다. 누군가는 대소문자만 구별하는 시스템만 사용하면 되지 않겠냐고 할 수 있겠지만, API를 만드는 이유는 API를 제공하는 서비스가 API를 제공받는 서비스를 직접 선택/제어 할 수 없다는 전제이다. API는 누구라도 사용할 수 있도록 정하는 것이 올바른 방향일 것이다. 결론 1. 카멜케이스는 읽기도 어렵고, URI 스펙에서 문제의 여지가 있을 수 있는데 사용하지 말자. 2. 혼선 있을수 있는 스네이크 케이스도 피하자. > 읽기도 쉽고 문제 소지가 적은 데시 케이스를 사용하자.
2019-03-14
박가람  소프트웨어 엔지니어 @파킹클라우드
246RP · Laravel framwork 상위 17%

블로그 글

채용 정보

유니코써치는 1984년 외국기업들의 한국 진출을 지원하는 '㈜유니코비즈니스써비스'의 HR사업부문으로서 국내 최초의 인재추천(고급인재채용자문) 서비스를 시작하였고, 1992년에 독립법인으로 확대 설립된 이후 20년 넘게 업계 개척자로서 정상을 지켜왔습니다. 유니코(Unico)는 'Unique Corporation'의 약자로서, 회사의 정체성인 '고유함(Uniqueness)'을 바탕으로 'Unique Fit', 'Unique Solution', 'Unique Partnership'을 유니코써치의 기본전략으로 삼고 있습니다. 
로민
응답률 우수
컴퓨터비전 연구 전문 스타트업 Lomin 입니다. 

프로젝트

Telecare Service Platform
 
2015년 12월 | 진행중 
* 5분간 동시접속 5만 수용가능한 서버(IDC) 구축 * DB 이중화 / 몽고DB 레플리케이션 등의 DB 관리 * Netty를 활용한 TCP 서버 구축 * Spring Boot를 통한 IoT 데이터 파이프라인 구축 * Family (민간서비스 웹/모바일 앱), Admin, 데이터 분석 플랫폼 등 TSP 플랫폼 관련 13개 프로젝트 개발/운영 (Full-Stack, Infra) * 자체 OAuth 2 인증서버/리소스서버/개발자센터 개발 * 주요 기술스택: Java 8, Spring Boot 1.5 ~ 2, Netty 4 등
이민규  선임연구원, 웹 개발자, 데이터 엔지니어 @(주)하이디어솔루션즈
740RP · Java 상위 2%
서울시 유무선 통합홈페이지 고도화
2018년 7월 - 2018년 10월 
서울시에서 시민을 대상으로 모집, 신청, 추첨 등을 담당하는 이벤트 파트(관리자/사용자 페이지)를 개발하였습니다. * Synap 문서뷰어 API 연동 * Xfc Batch App API를 활용하여 문서 암호화 * 서울시 문자전송 API 연동 * 다음 지도 API 연동 * 시큐어코딩 및 웹 취약점 처리 * 이벤트 파트의 권한 설계 및 구현 * Oracle11g DML을 이용한 DB조작 및 조회 * EgovFramework와 JDK 1.7을 이용한 백엔드 개발 * JSTL와 jQuery를 사용하여 유효성 처리 및 이벤트 처리
문승찬  SW 개발자 @더모음
930RP · Java 상위 1%
호텔 무인 체크인/체크아웃 Kiosk
2019년 2월 | 진행중 
무인 체크인/체크아웃 Kiosk 프로젝트 입니다. 크롤링을 통해 PMS(호텔 객실 관리 시스템)에 동시 처리를 하였습니다. * Selenium을 활용 * Serial 통신을 활용한 디스펜서 조작 * Socket을 활용하여 Protocol 전송, 응답 * SpringFramework와 JDK1.8을 이용하여 백엔드 개발 * AWS EC2 서버 인프라 설계 및 구축과 편의성을 위한 AWS서비스 적용 * JNA를 활용한 도어락 프로그램 연동 * 언어팩 설정 * Mysql DML을 이용한 DB조작
문승찬  SW 개발자 @더모음
930RP · Java 상위 1%