반응형


[ 자바성능튜닝교육 회고 ]


월요일(20171030), 화요일(20171031) 이틀간 회사내에서 '자바성능튜닝 대한 교육을 6시간에 걸쳐 수강하였다.

교육도 들었겠다 관련해서 간단히 들었던 내용과 생각을 정리해보려한다.

먼저 성능을 튜닝하기 위해서는 무작정 '튜닝할거야' 라고 달려드는게 아니다.



번째로 튜닝을 하고자 하는 어플리케이션의 어떤 부분에서 병목이 발생하고 있는지 살펴볼 필요가 있다.

어떤 부분에서 병목이 발생하는지 발견했다면 튜닝을 하기전 요청에 대한 response time 철저하게 체크하고 확인해보자.

추후 효율적으로 튜닝이 되었는지 확인을 위한 필수적인 부분이다.

일반적인 어플리케이션에서 병목이 발생하는 부분은 대부분 DB관련된 부분일 확률이 높다.


성능 튜닝에 있어서 기본은  throughput(처리량), response time(응답시간) 척도가 있다.

먼저 throughput(처리량) 경우 특정한 시간내에 얼마나 많은 transaction 처리할 있느냐가 중요하다.

처리량은 보통 TPS, TPM, TPH 표시한다.

TPS = Transaction Per Seconds

TPM = Transaction Per Minutes

TPH = Transaction Per Hours

3,600 TPH = 60 TPM = 1 TPS

일반적으로는 TPS 가장 많이 사용하고 TPS 높으면 높을 수록 좋다.

반면에 요청에 대한 response time(응답시간) 당연히 짧으면 짧을 수록 좋다고 있다.



만약 성능측정툴(scouter, jmap, jvh)등을 통해서 어플리케이션 내부를 튜닝할 경우에는 실제로 

cpu 가장 많이 사용하는 모듈(메소드, 라이브러리) 확인하고 코드 개선이 필요하다.

응답시간을 가장 많이 잡아먹는 메소드를 먼저 선행 튜닝하도록 하자.


다음과 같은 경우는 당연히 a 메서드에 대한 튜닝을 진행하는게 어플리케이션 전체 효율을 높이는데 효과적일 것이다.



또한 어플리케이션 개발 초기에 특정 프레임워크를 사용할 경우 먼저 선행 성능 측정이 필요하다.

만약 어플리케이션의 특정 프레임워크의 버전을 올려 배포해야 하는 상황이라면 기능 개선 작업과 함께 

배포하여 테스트하는 것은 지양하는 것이 좋다. 실제로 문제가 발생했을 프레임워크 버전업으로 인한 문제인지

추가된 로직들에 의한 문제인지 확인이 힘들기 때문이다. 



만약 간단하게 서버에 떠있는 자바 인스턴스에 대한 모니터링이 필요하다면 jvmtop 사용하는 것을 추천한다.

생각보다 손쉽게 해당 인스턴스의 CPU점유 쓰레드, 내부에서 동작하고 있는 메서드들에 대한 정보를 확인할 있다.

https://github.com/patric-r/jvmtop

 JvmTop 0.8.0 alpha   amd64  8 cpus, Linux 2.6.32-27, load avg 0.12

 https://github.com/patric-r/jvmtop


  PID MAIN-CLASS      HPCUR HPMAX NHCUR NHMAX    CPU     GC    VM USERNAME   #T DL

 3370 rapperSimpleApp  165m  455m  109m  176m  0.12%  0.00% S6U37 web        21

11272 ver.resin.Resin [ERROR: Could not attach to VM]

27338 WatchdogManager   11m   28m   23m  130m  0.00%  0.00% S6U37 web        31

19187 m.jvmtop.JvmTop   20m 3544m   13m  130m  0.93%  0.47% S6U37 web        20

16733 artup.Bootstrap  159m  455m  166m  304m  0.12%  0.00% S6U37 web        46



위의 내용 모두 중요하지만 가장 기본은 역시 코딩을 해당 코드가 어떻게 동작할지 어떻게 하면 메모리, cpu 적게 사용할 있을지


고민하면서 효율적인 코드를 작성하는 것이다.


'좋은 코드가 좋은 시스템을 만든다


반응형
반응형


작업 중 java.sql.SQLException: Before start of result set 오류가 발생하였다.



뭔가 하고 보니 소스코드에서 mysql에 질의를 던져 데이터를 가져와서 ResultSet에 담는데 ResultSet에서 데이터를 읽을 경우 cursor의 points를 첫 번째 로우에 맞추어주어야 한다.


즉, 결과값을 읽기전에 next() 메서드를 호출 후 사용 하여야 한다. 


[ 오류가 발생했던 소스코드 ] 




[ 문제 해결 소스코드 ] 



보다시피 result.next() 전에 result.getString()으로 값을 불러오려고 했을 때 문제가 발생했다.

result.next() while문 안으로 넣어서 해결~!

반응형
반응형

 

 안녕하세요. 오늘은 간단하게 자바 EXCEPTION처리시  EXCEPTION이 처리되는 우선순위에 대한 궁금증이 생겨 확인한 내용 간단히 공유해봅니다. 포스팅을 너무 장황하게 하려하니 글쓰는 수도 줄어들고 해서 앞으로는 간단히라도 자주 기록을 남기는 습관을 들이려합니다:)


상 황 ]

 2개의 exceptionHandler 클래스가 있고 범위는 다음과 같다.  

 

1번 - @ControllerAdvice("com.nhnent.webcc")       (프로젝트 전체 패키지)          

  -   (2번이 1번에 완전 귀속)   - 

2번 - @ControllerAdvice("com.nhnent.webcc.controller.api")  (API 관련 패키지) 


 

[ 궁금증 ]

2번 패키지 범위의 클래스에서 1번 범위의 메서드 실행하다가 에러가 발생할 경우 1번 handler에서 처리가 될지 2번 handler에서 처리가 될지?


예측이 되시나요? ㅎㅎ

 

동작확인  ]

실제로 1번 범위의 클래스에서 exception이 발생했을지라도 ExceptionHandlerExceptionResolver에 의해 메서드를 호출한 상위

클래스를 찾아가게 되고 그 클래스내에서 exception이 발생하게 된다. 따라서 2번 handler에 의해서 exception이 처리되게 된다.

 

궁금하시거나 잘못된 부분이 있다면 코멘트 부탁드립니다.




오늘도 좋은하루보내세요:)

 



반응형
반응형


 안녕하세요. 오늘은 ZIP파일 안의 파일 중 한글명으로 된 파일이 있을 경우 해당 파일에 접근하지 못하는 문제를 COMMONS COMPRESS라이브러리를 통해 해결한 방법을 공유하도록 하겠습니다. 최근 작업 중에 고객들이 넣는 문의들 중 파일 첨부된 ZIP 파일의 경우 해당 ZIP파일 내에 .exe파일이 있는지 확인해 인입이 안되도록 처리해야 하는 작업이 있었습니다. 처음엔 COMMONS COMPRESS를 사용하지 않고 ZIP파일내의 파일들의 확장자를 확인하는 방법으로 작업하였습니다. 작업 후 테스트 결과 ZIP 파일 내에 한글명으로 된 파일이 있을 경우 제대로 파일내의 ZIPENTRY에 접근을 하지 못하는 문제점을 발견할 수 있었습니다. COMMONS COMPRESS 라이브러리를 통해 해결하였고 그 방법에 대해 포스팅하도록 하겠습니다.


[ 코 드 ]  

 


코드에서 보면 알겠지만 ZIP파일을 굳이 따로 디렉토리를 만들어 압축을 푼 후 체크하지 않고 ZipEntry를 통해 ZIP파일의 파일들에 접근하는 것을 볼 수 있다. 이렇게 JDK에서 지원하는 java.util.zip을 사용했을 경우 위에서 언급했던 대로 ZIP파일 내에 한글 파일 처리를 할 수 없는 문제가 발생합니다. 이를 해결하기 위한 방법으로는 jazzlib 및 commons-compress를 사용하는 방법이 있는데 jazzlib 같은 경우 라이브러리 자체도 상당히 오래 되었고 라이센스 문제가 발생할 수 있어 commons-compress를 사용하게 되었다. 



[ Commons Compress 적용 ]

먼저 메이븐 프로젝트이기 때문에 dependency를 추가해주었다. 

 


라이브러리를 추가 하고 다음과 같이 변경하였다.

 

다른 점은 ZipArchiveInputStream을 사용하여 인코딩 방식을 EUC-KR로 지정해 주었다. 수정 후 테스트를 해본 결과 ZIP파일 내에 한글명의 파일이 있을 경우에도 정확히 처리하는 것을 확인 할 수 있었다.



반응형
반응형

최근 자바 어플리케이션에서 hdfs파일을 local파일로 쓰는 외부 명령을 실행시켜야 하는 작업이 있었다.


Runtime 객체를 생성하고 exec 메소드를 이용하여 외부 명령을 실행시키는 프로세스를 생성하였다.


코드를 보면 알겠지만 command 명령에 파이프라인(|)이 사용되었다.


Runtime runtime = Runtime.getRuntime();

Process process = null;


String command = "hadoop fs -text /log/dmp_log/2017/09/19/dmp_log.*.1505786400000.gz | head -100"


process = runtime.exec(command);


이렇게 해서 동작을 시키니 100라인만 읽어와야하는데 해당 hdfs파일의 모든 로그를 읽어왔었다...


한참을 헤매다가 파이프라인(|)이 안먹는다는 생각이 들었고 찾아보니 문제가 있었다.


파이프라인(|)을 사용하는 것은 shell 실행 후 또 다른 프로세스로 실행하기 때문에 정상적으로 작동을 안한 것이다.


다음과 같이 해결을 하면 된다.


String commandHdfs = "hadoop fs -text /log/dmp_log/" + date + "/dmp_log.*." + unixTime + "000.gz | head -150";


String[] command = {

      "/bin/sh",

      "-c",

     commandHdfs

};


[ stack overflow 참고 ]

https://stackoverflow.com/questions/5928225/how-to-make-pipes-work-with-runtime-exec


간단히 요약하자면, 자바 어플레케이션에서 exec로 실행하는 system command는 실제로 unix, linux의 shell을 불러와 명령을 실행시키는게 아니라고하네요.


그렇기 때문에 쉘의 기능(shell feature)인 pipeline (파이프라인)을 사용하기 위해서는 명시적으로 shell(/bin/sh)을 불러주고 


해당 쉘 안에서 command를 실행시켜야 한다고 합니다.


더 정확한 원인을 알고 싶다면 참고부탁드려요

https://alvinalexander.com/java/java-exec-system-command-pipeline-pipe

반응형
반응형

데이터 엔지니어로 살아가기 143일째(커스텀타겟팅) - 0721금요일


광고주 태그매니저에서 들어오는 데이터들을 orc로 적재하는 작업을 마무리하였다.


camus를 통해 kafka에서 데이터를 가져와 매시간 데이터를 적재하고 있지만


커스텀타겟팅에 사용하기에는 부적합하다는 판단에 orc로 적재하기로 결정하였다.



작업을 완료하기까지 많은 수행착오를 겪었다. 인입되는 로그에서 실제 bid별 관심사를


추출해 적재하기로 사전에 얘기가 되었지만 실제로 작업을 완료하고 확인해보니 


생각보다 관심사를 추출하는 부분에서 처리시간이 많이 소모되었다. 


관심사 추출 후 date, action별로 partitioning하여 적재하는 시간이 단순 컬럼으로만 분리해서


적재했을 때의 시간보다 15배정도의 시간이 더 걸렸다.t.t

 


결국에는 일단 orc로 적재한 후 관심사 데이터가 필요할 경우 bid별 관심사 추출데이터와


join해서 사용하는 편이 리소스 활용측면이나 확장성 측면에서 더 효율적이겠다는 결정을 내렸고 


scala spark으로 다시 orc 적재하도록 마무리하였다.



orc적재 작업을 진행하면서 java-spark에 어느정도 더 익숙해졌고 관심사 추출로직에 대해


심도있게 파악할 수 있었다는 점에서 삽질도 많이했지만 좋은 기회가 되었던 것 같다.


이제 실제 커스텀타겟팅 메인 프로젝트 작업에 슬슬 시동을 걸어봐야겠다~


아! 그리고 틈틈히 scala공부를 하도록하자~scala 와 spark는 뗄래야 뗄 수 없는 관계

반응형
반응형

최근 작업중 unix date를 파싱해야는 경우가 있어서 아무렇지 않게


String unixDate = "1498906817.357"

String[] parseDate = unixDate.split(".");

String parsedDate = Long.parseLong(parseDate[0]);


다음과 같이 썼는데 파싱된 데이터에 값이 안들어있다는...


확인해보니 split의 인자로 들어가는  .(dot)이 정규식이기 때문이었다. 

정규식에서는 .(dot)은 무작위의 한글자를 의미하므로 모든 문자가 토큰이 되기 때문에 배열에 남는게 없게 되는 것이다.

그렇기 때문에 이를 피하기 위해서는 이스케이프(\\)를 문자앞에 써줘야 한다.



String unixDate = "1498906817.357"

String[] parseDate = unixDate.split("\\.");

String parsedDate = Long.parseLong(parseDate[0]);


뭔가 split 메서드를 사용해 parsing을 했는데 값이 정상적으로 나오지 않는다면 정규식을 의심하자.



[ 참고 ]

there are 12 characters with special meanings: the backslash \, the caret ^, the dollar sign $, the period or dot ., the vertical bar or pipe symbol |, the question mark ?, the asterisk or star *, the plus sign +, the opening parenthesis (, the closing parenthesis ), and the opening square bracket [, the opening curly brace {, These special characters are often called "metacharacters".

반응형
반응형


 안녕하세요. 오늘은 프로세스와 스레드에 대해서 알아보도록 하겠습니다. 많은 분들이 실제로 프로세스와 스레드를 알고 계시면서도 막상 물어보면 대답하기 막막해하시는 경우도 많이 있고 저도 실제로 프로세스&스레드에 대해서 명확히 설명하기 힘들어 했던 경험이 있어 이번 기회에 한 번 간단히 개념적인 부분에 대해서 정리하고 넘어가려고 합니다. 이제 막 2년차에 접어드는 현업 개발자지만 요즘 느끼는 것은 새로운 기술들에 관심을 가지는 것도 중요하지만 개발을 함에 필요한 '기본적인 내용들과 지식을 좀 더 단단히 쌓아야 겠다'는 생각이 많이 들곤 합니다. 포스팅 시작하도록 하겠습니다.



[ PROCESS ]

 먼저 프로세스란 간단히 설명해서 실행중인 프로그램에 대한 인스턴스를 프로세스라고 합니다. 실제로 프로세스가 생성되게 되면 해당 프로세스는 운영체제로부터 주소공간, 파일, 메모리 등을 할당받게 됩니다. 그리고 메모리 공간은 CODE, DATA, HEAP, STACK영역으로 나뉘어지게 됩니다. 실제로 프로세스가 처리해야 될 일을 각각의 메모리 영역들 위에서 처리하게 되게 됩니다.

프로세스는 다음과 같은 독립된 메모리공간을 프로세스별로 가지게됩니다. (스레드 설명할 때 설명하겠지만 스레드는 STACK 부분만 독립적으로 가지게 됩니다.) 그렇기 때문에 특정 PROCESS가 다른 PROCESS 메모리에 직접 접근하기 힘듭니다.


[ THREAD ]

 스레드란 프로세스 안에서 동작되는 여러 실행의 흐름이라고 보시면 됩니다. 간단히 말해서 프로세스 내부에서 실제로 일을 하는 녀석들을 스레드라고 합니다. 우리 몸으로 치면 몸은 프로세스 손,발은 스레드 정도가 되지 않을까요?(단순한 제 생각) 기본적으로 하나의 프로세스가 생성되면 하나의 스레드가 같이 생성이됩니다. 이를 메인 스레드라고 부르며, 스레드를 추가로 생성하지 않는 한 모든 프로그램 코드는 메인 스레드에서 실행이 된다고 생각하시면 됩니다. 또한 프로세스는 메인 스레드 외에도 여러개의 스레드를 가질 수 있는데요. 이를 멀티스레드라고 합니다.

 스레드의 경우에도 프로세스와 같이 메모리 공간을 할당 받게 되는데요. 프로세스가 각각의 독립적인 메모리 공간을 할당받는 반면에 스레드의 경우는 Stack영역만을 독립적으로 할당 받게 됩니다. 실제로 Code, Data, Heap영역은 프로세스의 공간을 공유받아 사용하게 됩니다. 이렇듯 프로세스 내에서 생겨나는 모든 스레드의 경우 Stack이외의 영역은 프로세스의 영역을 공유받아 사용하게 되고 이러한 이유로 인해 스레드간 Context Switching(아래에 간단히 설명)이 발생했을 경우 Stack 영역의 데이터들만 switching되면 되므로 프로세스 스위칭보다 훨씬 빠르게 진행이 됩니다. 스레드의 장점으로는 시스템의 Throughput(처리량)이 향상 되며, 자원 소모가 줄어들고 스레드간의 스위칭 시간이 줄어들면서 일을 처리할 때 응답 시간이 단축되는 점이 있습니다. 반면에 여러 개의 스레드를 사용할 때는 프로세스가 가지고 있는 메모리 영역의 자원 공유의 문제가 발생할 수 있고 디버깅이 힘들다는 점이 있습니다. 마지막으로 프로세스의 메모리 영역(Data, heap)을 공유함으로써 전역 변수와 동적 할당 딘 메모리 공간을 공유하게 되고 이를 통해 쓰레드간 통신이 쉽게 가능하게 됩니다.


[ THREAD가 스택을 독립적으로 할당하는 이유 ]

 스택은 함수 호출 시 전달되는 인자, 되돌아갈 주소 값 및 함수 내에서 선언하는 변수 등을 저장하기 위해 사용되는 메모리 공간입니다. 따라서 스택 메모리 공간이 독립적이라는 것은 독립적인 함수 호출이 가능하다는 것이고, 이는 독립적인 실행흐름을 가질 수 있다는 것입니다. 결과적으로 실행 흐름의 추가를 위한 최소 조건이 독립된 스택을 제공하는 것이라고 볼 수 있습니다.


[ Context  Switching 이란? ]

 프로세스를 이것저것 우선 순위에 따라 변경하기 위해서는 실제로 작업에 사용되는 프로세스 데이터를 레지스터와 메모리 사이를 왕복하며 값을 복사해야 합니다. 보통 cpu에 의해 프로세스가 일을 처리하게 되는데 스케줄링 방식에 따라 특정 프로세스가 일을 진행하고 있다가 다른 프로세스에게 cpu사용권을 넘겨주게 될 때 어디까지 작업을 했고 다음부터는 어디서부터 작업을 해야하는지에 대한 정보를 보관할 수 있는 곳이 필요하고 이러한 정보들을 프로세스에 맞게 변경해주고 처리하는 것을 말합니다. 실제로 CPU는 동시에 한 개씩만 스레드를 실행시킬 수 있는데 스레드가 여러개가 생성되게 되면 CPU는 각각의 스레드를 번갈아가며 실항하게 되는데, 이 때 이전 스레드의 문맥 정보(레지스터 값, 실행중인 스택 정보 등)을 백업받고 백업 받아놓았던 다음 스레드의 문맥정보를 로딩하는 과정을 거치게 됩니다. 이 과정을 Context Switchig이라고 합니다. 이러한 스레드가 많아질 수록 Context Switching에 많은 부하가 걸리기 때문(메모리와 레지스터 사이의 데이터 이동도I/O이다)에 잘 고려해서 사용해야 되겠습니다.  


오늘 포스팅은 여기까지 하도록 하겠습니다. 잘못된 부분이나 설명이 부족한 부분은 댓글로 남겨주시면 참고하도록 하겠습니다. 감사합니다.




반응형
반응형

 


 [ REST API 제대로 알고 사용하기 ]

 어느 날 뜬금없이 대학교 친구에게 전화가 왔습니다. 그러더니 ‘야, REST API가 정확히 뭐 어떤 거야?’ 하는 질문에 가슴에 비수가 날아와 꽂힌 듯한 느낌을 받았습니다 . 며칠 전 카톡으로 요즘 보통 웹서비스들은 ‘REST API형태로 서비스를 제공한다’고 아는 척을 조금 했던 기억이 머릿속을 빠르게 스쳐 지나갔고 그 순간 대충 얼버무리며 ‘아, 그거 REST하게 클라이언트랑 서버간에 데이터를 주고 받는 방식'을 말한다며 얼렁뚱땅 마무리 지었던 기억이 납니다.  실제로 REST API의 서비스를 직접 개발도 해보고 사용도 해봤는데도 막상 설명을 하자니 어려움을 겪었던 적이 있으셨을텐데요. 그래서 이번에 REST API에 대해 정리하게 되었습니다. 기본적인 REST API에 대한 내용 외에도 REST API를 설계하실 때 참고해야 할 몇 가지 TIP들에 대해 공유해보도록 하겠습니다. 


1. REST API의 탄생

   REST는 Representational State Transfer라는 용어의 약자로서 2000년도에 로이 필딩 (Roy Fielding)의 박사학위 논문에서 최초로 소개되었습니다. 로이 필딩은 HTTP의 주요 저자 중 한사람으로 그 당시 웹(HTTP) 설계의 우수성에 비해 제대로 사용되어지지 못하는 모습에 안타까워하며 웹의 장점을 최대한 활용할 수 있는 아키텍쳐로써 REST를 발표했다고 합니다.


2. REST 구성

쉽게 말해 REST API는 다음의 구성으로 이루어져있습니다. 자세한 내용은 밑에서 설명하도록 하겠습니다.

자원(RESOURCE) - URI

행위(Verb) - HTTP METHOD

표현(Representations)


3. REST 의 특징

1) Uniform (유니폼 인터페이스) 

: Uniform Interface는 URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 말합니다.


2) Stateless (무상태성) 

: REST는 무상태성 성격을 갖는다. 다시 말해 작업을 위한 상태정보를 따로 저장하고 관리하지 않는다. 세션 정보나 쿠키정보를 별도로 저장하고 관리하지 않기 때문에 API 서버는 들어오는 요청만을 단순히 처리하면 된다. 때문에 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순해진다.


3) Cacheable (캐시 가능) 

: REST의 가장 큰 특징 중 하나는 HTTP라는 기존 웹표준을 그대로 사용하기 때문에, 웹에서 사용하는 기존 인프라를 그대로 활용이 가능하다. 따라서 HTTP가 가진 캐싱 기능이 적용가능하다. HTTP 프로토콜 표준에서 사용하는 Last-Modifyed태그나 E-Tag를 이용하면 캐싱 구현이 가능하다.


4) Self-descriptiveness (자체 표현 구조) 

: REST의 또 다른 큰 특징 중 하나는 REST API 메시지만 보고도 이를 쉽게 이해 할 수 있는 자체 표현 구조로 되어 있다는 것이다.


5) Client - Server 구조 

: REST 서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보)등을 직접 관리하는 구조로  각각의 역할이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로간 의존성이 줄어들게 된다.


6) 계층형 구조 

: REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 한다.



4. REST API 디자인 가이드

! REST API 설계시 가장 중요한 항목은 다음의 2가지로 요약할 수 있습니다.

첫 번째, URI는 정보의 자원을 표현해야 한다.

두 번째, 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.

다른 건 다 잊어도 위 내용은 꼭 기억하시기 바랍니다.


4-1  REST API 중심 규칙

1) URI는 정보의 자원을 표현해야한다. (리소스명은 동사보다는 명사를 사용)

GET /members/delete/1

 

위와 같은 방식은 REST를 제대로 적용하지 않은 URI입니다. URI는 자원을 표현하는데 중점을 두어야 합니다. delete와 같은 행위에 대한 표현이 들어가서는 안됩니다.


2) 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)로 표현

 위의 잘못 된 URI를 HTTP Method를 통해 수정해 보면

DELETE /members/1

로 수정할 수 있겠습니다. 회원정보를 가져올 때는 GET, 회원 추가시의 행위를 표현하고자 할 때는 POST METHOD를 사용하여 표현합니다.

 

회원정보를 가져오는 URI

GET /members/show/1     (x)

GET /members/1          (o) 

 

회원을 추가할 때

GET /members/insert/2 (x)  - GET 메서드는 리소스 생성에 맞지 않는다.

POST /members/2       (o)

 

**[참고]HTTP METHOD의 알맞은 역할 **

POST, GET, PUT, DELETE 이 4가지의 Method를 가지고 CRUD를 할 수 있다. 

| POST | POST를 통해 해당 URI를 요청하면 리소스를 생성합니다. |

| GET | GET를 통해 해당 리소스를 조회 합니다. 리소스를 조회하고 해당 도큐먼트에 대한 자세한 정보를 가져온다. |

| PUT | PUT를 통해 해당 리소스를 수정 합니다. |

| DELETE | DELETE를 통해 리소스를 삭제합니다. |

다음과 같은 식으로 URI는 자원을 표현하는데에 집중하고 행위에 대한 정의는 HTTP METHOD를 통해 하는 것이 REST한 API를 설게하는 중심 규칙입니다.



4-2 URI 설계시 주의할 점

1) 슬래시 구분자(/)는 계층 관계를 나타내는 데 사용

EX )  * http://restapi.example.com/houses/apartments

         * http://restapi.example.com/animals/mammals/whales


2) URI 마지막 문자로 슬래시(/)를 포함하지 않는다 

: URI에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 하며 URI가 다르다는 것은 리소스가 다르다는 것이고, 역으로 리소스가 다르면 URI도 달라저여한다. REST API는 분명한 URI를 만들어 통신을 해야하기 때문에 혼동을 주지 않도록 URI 경로의 마지막에는 /를 사용하지 않는다.

http://restapi.example.com/houses/apartments/ (X)

http://restapi.example.com/houses/apartments  (0)


3) 하이픈(-)은 URI 가독성을 높이는데 사용 

: URI를 쉽게 읽고 해석하기 위해, 불가피하게 긴 URI경로를 사용하게 된다면 하이픈을 사용해 가독성을 높일 수 있다.


4) 밑줄(_)은 URI에 사용하지 않는다. 

: 글꼴에 따라 다르긴 하지만 밑줄은 보기 어렵거나 밑줄 때문에 문자가 가려지기도 한다. 이런 문제를 피하기 위해 밑줄 대신 하이픈을 사용하자(가독성)


5) URI 경로에는 소문자가 적합하다. 

: URI 경로에 대문자 사용은 피하도록 하자. 대소문자에 따라 다른 리소스로 인식하게 된다. RFC 3986(URI 문법 형식)은 URI 스키마와 호스트를 제외하고는 대소문자를 구별하도록 규정하기 때문이지요.

(*RFC 3986 is the URI (Unified Resource Identifier) Syntax document)


6) 파일 확장자는 URI에 포함시키지 않는다.

http://restapi.example.com/members/soccer/345/photo.jpg (X)

REST API에서는 메시지 바디 내용의 포맷을 나타내기 위한 파일 확장자를 URI 안에 포함시키지 않는다. Accept header를 사용하도록 합시다.

GET / members/soccer/345/photo HTTP/1.1 Host: restapi.example.com Accept: image/jpg



4-3 리소스간의 관계를 표현하는 방법

: REST 리소스 간에는 연관 관계가 있을 수 있고 다음과 같은 표현방법으로 사용하자.

/리소스명/리소스 ID/관계가 있는 다른 리소스명

ex) GET : /users/{userid}/devices  (일반적으로 소유 ‘has’의 관계를 표현할 때)

만약에 관계명이 복잡하다면 이를 서브 리소스에 명시적으로 표현하는 방법이 있다. 예를 들어 사용자가 ‘좋아하는’ 디바이스 목록을 표현해야 할 경우 다음과 같은 형태로 사용될 수 있다.

GET : /users/{userid}/likes/devices (관계명이 애매하거나 구체적 표현이 필요할 때)



4-4 자원을 표현하는 Colllection과 Document

: Collection과 Document에 대해 알면 URI 설계가 한 층 더 쉬워집니다. DOCUMENT는 단순히 문서로 이해해도 되고, 한 객체라고 이해하셔도 될 것 같습니다. 컬렉션은 문서들의 집합, 객체들의 집합이라고 생각하시면 이해하시는데 좀 더 편하실 것 같습니다. 컬렉션과 도큐먼트는 모두 리소스라고 표현할 수 있으며 URI에 표현됩니다. 예를 살펴보시도록 하겠습니다.

http:// restapi.example.com/sports/soccer

위 URI를 보시면 sports라는 컬렉션과 soccer라는 도큐먼트로 표현되고 있다고 생각하시면 됩니다. 좀 더 예를 들어보자면

http:// restapi.example.com/sports/soccer/players/13

sports, players 컬렉션과 soccer, 13(13번인 선수)를 의미하는 도큐먼트로 URI가 이루어지게 됩니다. 여기서 중요한 점은 컬렉션은 복수로 사용하고 있다는 점입니다. 좀 더 직관적인 REST API를 위해서는 컬렉션과 도큐먼트를 사용하실 때 단수 복수도 지켜주신다면 좀 더 이해하기 쉬운 URI를 설계하실 수 있을 것 같습니다.
 


5. HTTP 응답 상태 코드

마지막으로 응답 상태코드를 간단히 살펴보도록 하겠습니다. 잘 설계된 REST API는 URI만 잘 설계된 것이 아닌 그 리소스에 대한 응답을 잘 내어주는 것 까지 포함되어야 합니다. 정확한 응답의 상태코드만으로도 많은 정보를 전달할 수가 있기 때문에 응답의 상태코드 값을 명확히 돌려주는 것은 생각보다 중요한 일이 될 수도 있습니다. 혹시 200이나 4XX관련 특정 코드 정도만 사용하고 계시다면 처리 상태에 대한 좀 더 명확한 상태코드 값을 사용하실 수 있기를 권장하는 바입니다.

상태코드에 대해서는 몇 가지지만 정리하도록 하겠습니다.



200 - 클라이언트의 요청을 정상적으로 수행함

201 - 클라이언트가 어떠한 리소스 생성을 요청, 해당 리소스가 성공적으로 생성됨(POST를 통한 리소스 생성 작업시)


400 - 클라이언트의 요청이 부적절 할 경우 사용하는 응답 코드

401 - 클라이언트가 인증되지 않은 상태에서 보호된 리소스를 요청했을때 사용하는 응답 코드 (로그인 하지 않은 유저가 로그인했을 때 요청 가능한 리소스를 요청했을 때)

403 - 유저 인증상태와 관계 없이 응답하고 싶지 않은 리소스를 클라이언트가 요청했을 때 사용하는 응답 코드 (403 보다는 400이나 404를 사용할 것을 권고. 403자체가 리소스가 존재한다는 뜻이기 때문에)

405 - 클라이언트가 요청한 리소스에서는 사용 불가능한 Method를 이용했을 경우 사용하는 응답 코드


301 - 클라이언트가 요청한 리소스에 대한 URI가 변경 되었을때 사용하는 응답 코드 (응답시 Location header에 변경된 URI를 적어 줘야 한다.

500 - 서버에 문제가 있을 경우 사용하는 응답 코드


[ 글을 마치며 ]

그래서 'REST API가 정확히 뭐 어떤 거야?'라고 다시 묻는 다면 'HTTP METHOD와 자원을 표현하는 URI를 이용해 서비스의 데이터에 접근하는 것' 라고 제 나름의 정의를 내려보았습니다. 물론 비전공자인 친구에게는 추가적인 설명이 필요할 것 같습니다. 


RESTFul한 API를 설계하실 때 도움이 될 만한 내용들을 제 나름의 우선순위를 가지고 정리해 보았습니다. 정리를 하면서 다시 한 번 느낀 것은 정확히 알지 못하면 '설명할 수 없다'는 것입니다. 누군가가 그런 말을 하였습니다. '당신이 어떤 것을 할머니에게 설명해 주지 못한다면, 그것은 진정으로 이해한 것이 아니다.' 저 문구를 항상 가슴 깊이 새기고 앞으로 무엇인가 새로운 지식을 학습해 실무에 적용할 때에도 '대충'이 아닌 '정확한 이해'를 바탕으로 문제를 해결해 나가도록 해야겠다'는 다짐과 함께 글을 마무리 짓도록 하겠습니다.


마지막으로 REST API는 정해진 명확한 표준이 없기 때문에 REST API를 사용함에 있어 '무엇이 옳고 그른지'가 아닌 개발하는 서비스의 특징과 개발 집단의 환경과 성향 등이 충분히 고려되어 설계되어져야 할 것입니다

 

 

긴 글 읽어주셔서 감사합니다.


[ Reference ]

- 일관성 있는 웹 서비스 인터페이스 설계를 위한 REST API 디자인 규칙(한빛미디어)

https://ko.wikipedia.org/wiki/REST

http://blog.remotty.com/blog/2014/01/28/lets-study-rest/

https://yangbongsoo.gitbooks.io/study/content/restc758_c774_d574_c640_c124_acc4.html

http://spoqa.github.io/2012/02/27/rest-introduction.html


#NHN엔터테인먼트가 만드는 IT 서비스를 소개하고, 개발 경험을 공유하는 기술 커뮤니티 이고 해당 페이지에 게시한 글입니다.

많은 구독부탁드립니다:)

https://www.facebook.com/toast.nhnent/?fref=ts 


반응형

+ Recent posts