어제보다 더 나은 개발자 되기

SQL JOIN에 대해 집합으로 잘 표현된 자료가 있다 

출처 : http://rapapa.net/?p=311

기본적인 JOIN문의 형태는 

SELECT column1, column2, column3..... 

FROM TableA A

(LEFT / RIGHT / FULL / INNER) JOIN TableB B

ON A.Key = B.Key

LEFT / RIGHT / FULL 은 OUTER Keyword를 써서 나타낼 수도 있다 (안 써도 결과는 같다)

위의 집합관계 그림에서 

- 차집합 Set(A-B) or Set(B-A)

- Set(U) - Set(A∩B) 

과 같은 경우 조건을 추가해서 나타내는 방법이 있다 

WHERE 절을 추가해서 반대 방향의 테이블의 Key(맵핑되는 컬럼) 가 IS NULL일 때 순수하게 한쪽에만 속하는 원소(Row)를 가져온다

아래 예제를 보자 

예제 data는 Oracle XE 버전을 설치하면 제공되는 기본 Scott DB를 이용했다 

ex)

SELECT * 

FROM EMP A

RIGHT OUTER JOIN DEPT B

ON A.DEPTNO = B.DEPTNO

SELECT * 

FROM EMP A

RIGHT OUTER JOIN DEPT B

ON A.DEPTNO = B.DEPTNO

WHERE A.DEPTNO IS NULL

차이가 느껴지는가?? 

JOIN의 결과는 INNER 처럼 Key가 같은 내용을 찾아주지만 LEFT나 RIGHT와 같이 쓰이면 한쪽에만 존재하는 data를 포함하게 된다 

그 반대방향의 Key가 Null인 경우만 필터링하면 순수한 A or B Table의 data를 가져올 수 있다 

교집합에 속하는 data를 가져와야 하는지 

차집합에 속하는 data를 가져와야 하는지 

그것에 따라 RIGHT 나 LEFT 또는 INNER를 잘 쓰도록 하자

오라클자바 커뮤니티 

http://www.oraclejavanew.kr/

오라클/자바/닷넷 강좌

https://www.software.kr/um/um01/um0106/um010603/um010603List.do?s_gubun=BK283

https://prezi.com/vtebfcg7bvss/sw-olc/

https://trello.com/b/pHKkTfHn/%EC%95%B1%EA%B0%9C%EB%B0%9C-%EB%AA%A8%EC%9E%84-%EC%A0%95%EB%B3%B4-%EB%B3%B4%EB%93%9C

노트북에 있는 내용을 정리(삭제)하다 어려운 말을 발견했다

분명 텍스트파일에 쓴 기억은 있는데 내가 한 말인지 다른사람이 한말을 붙여 넣기한건지 잘 모르겠다

근데 문맥이... 다른 사람이 한 말을 가져온 것 같기는 한데 내 생각도 있는건가??  같기도 하다... 

문제의 말은 아래와 같다

-------------------------------------------------------------------------------------------

자신의 방향성이 확고하지 않다면 타인의 사소한 공격에도 쉽게 혼란스러울 수 있다.
역사를 한번 봐라 위대한 성취를 이루거나 자신만의 업적을 남긴 이는 당대에 힐난과 조롱의 대상이었던 적이 많았음을 어렵지 않게 알 수있다.

속물 근성이 가득한 세상에서 자신의 존재를 지키는 것은 쉽지 않은 일이다

자칫 아집과 독선에 빠질 위험성이 있음에도 타인의 시선에 자유로워야 함을 말하는 것은 자신과 타인에 대한 균형잡힌 시선으로 더 객관적이고 문제에 대한 비판적인 판단을 올바르게 할 수 있기를 바란다.  

---------------------------------------------------------------------------------------------

왜 저런 어려운 말을 2015-04-19일날 적었을까?? 4/19혁명 관련 누가 쓴 글은 본 걸까??

멘 윗 문단은 옳다고 생각하는 기준에 대해 흔들리지 말라는 것 같고

아랫 문단은 비판적 사고를 함에 있어 객관성을 가지라는 것 같다....

두 문단간 연관성은 떨어져 보인다 다만 윗문단에서는 자칫 독선에 빠질 수 있을 것 같고 아랫 문단에서 올바른 판단을 하라는 것 같다..

괜히 건드려서 덧붙여봤자 자칫 뻔한 말이 될 수 있기도 하고 위의 말은 원본 그대로 그냥 두고자 한다 

다만 관련성이 있는 것은 아니지만 저것을 보고 남기고자 하는 말은 아래 문단과 관련있다 

바로 문제를 분석하는 방법과 비판적 사고이다 

대학생과 같이 고등교육을 받거나 또는 그런 고등교육의 지향점 혹은 세상을 바로보는 눈을 가지려면 필요한 능력으로 2가지를 꼽는다

하나는 분석적 사고(통계학을 배워보는 것도 비슷하다) 능력과

하나는 비판적 사고 이다.

문제를 분석하는 능력은 현재 상황에 대한 인식과 내 주장을 하기 위한 근거를 만들기 위해 필요하고

비판적 사고는 왜? 라는 질문과 답을 내리기 위해 필요하다 (차이나는 클라스 - 폴 김교수 편도 기회되면 한번 보자)

나는 이 두 가지만 제대로 배워 나와도 지성인으로 보인다 근데 생각보다 스스로 질문을 내리고 그 답을 찾는 사람들이 많지는 않은 것 같다..

우리나라 교육?? 그런 문제가 많다고 한다..

나 역시 아무생각 없이 25까지 살았으니 조금 분하긴 하다 교육과정과 그 공부에 대해 의문이나 호기심을 가지지 못했으니...

다만 그때나 지금이나 문제를 푸는 것은 재미있는 일이다. 

성인이 되어서 육하원칙을 이해하고 어마어마한 파급력을 발견했을 때 비로소 비판적 사고를 시작할 수 있었고 운 좋게 통계학을 배워본 것은 나름 분석할 데이터를 찾는 연습을 할 수 있던 것 같다 만약.. 조금만 더 일찍 공부를 재개 할 수 있었다면.. 뭔가 달라졌을까?

솔직히 나이 먹으면서 기억력은 옛날보다 안좋아지는 것 같은 느낌은 있다... ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ(술이 문제일까...?)

꾸준히 분석하는 능력과 비판적 사고 능력을 기르자...

동일한 질문을 반복하는 이유는 내 스스로 비판적 사고를 하기 위함이다

 재귀호출은 함수가 완료되기 이전에 자기자신을다시 호출하는 것이다.

 재귀알고리즘을 사용하려면 탈출 조건이 성립해야 한다.

 재귀는 트리구조이고 트리구조는 스택으로 되어있다

 즉 먼저 호출된 재귀가 나중에 탈출하고 가장 마지막에 호출된 재귀함수부터 진행이 된다.

 구조상으로

 함수호출1 --> 함수호출2 --> 함수호출3 --> 함수호출4 --> 함수호출5 --> 함수호출6 --> 종료조건

--> 함수탈출6 --> 함수탈출5 --> 함수탈출4 --> 함수탈출3 --> 함수탈출2 --> 함수탈출1 --> 프로그램종료

스택 구조인 것이 이해되는가?

트리를 이야기 한 것은 최상위 노드(첫 재귀호출)부터 반복적으로 재귀호출이 되면서 위에서 아래단계로 함수호출이 이루어진다.

단순 재귀일 경우 선형으로 보이지만 재귀 안에 재귀가 두 개일 경우 분기를 가지게 되어 트리 구조를 이루게 된다 

Ex)

Int Fibo(int n)

{

           If(n == 1 )

             return 0;

          else if ( n == 1 )

             return 1;

       else

         return Fibo(n-1) + Fibo(n-2);     // Tree 구조 처럼 함수호출이 진행 된다.

}

재귀 구조를 사용하려면 두 번째 시도 이후부터는 탐색 대상을 찾을 때까지 동일한 패턴을 반복한다.

------------------------------------------------------------------------------------------------------------------------------------------

동일한 패턴을 반복한다... 이 말이 중요한 것 같다.. 재귀는 직접 코드를 짜보면서 이해하자..

알고리즘을 평가하는 요소

시간복잡도 – 어떤 알고리즘이 더 빠르고 느린지 속도에 관한 것

공간복잡도 – 메모리를 적게 쓰고 많이 쓰는 지와 같은 메모리 사용량에관한 것

최적의 알고리즘은 메모리를 적게 쓰고 속도가 빠른 것

일반적으로는 속도에 초점을 둔다 속도에서의 기준은 연산 횟수를 들 수 있다.

책에서는 비교연산 즉 ‘==’ 값의 동등을 비교하는 연산을 적게 수행하는탐색알고리즘이 좋은 것이라고 나타나 있다

Ex)

for( I = 0 ; I < len ; i++ )

{

   If( ar[i] == target )       // 알고리즘의 복잡도를 분석할 수 있는 연산 부분

     return;

}

알고리즘의 성능 판단 – 최악의 경우로 비교한다

이유: 평균적인 경우로 판단해야 맞는다고 생각하기 쉽지만 실제로 평균을계산하거나 판단하기가 쉽지 않다 그리고 최악의 경우에 수행되는 연사의 횟수가 최선의 경우보다 더 큰 차이를 보이므로 대조하여 분석하기 쉽다.

부연 설명: 이를 평균적으로 계산하기 위해서는 다양한 이론이 적용되어야하고 분석에 필요한 여러 가지 시나리오와 데이터를 현실적이고 합리적으로 구성해야 정확한 시뮬레이션이 되는데 시간과 비용이 이를 감당하기 쉽지 않으므로쉽게 판단 가능한 최악의 경우로 비교하는 것이다.

• 의문 – 최악의 경우로만 비교할 경우 생기는부작용은 없는가??  확률적인 느낌이다.. 정답은 없을 듯

빅-오 표기법

빅오 – 성능분석의 도구

시간복잡도라는 함수 T(n)에서 가장 영향력이 큰 부분이 어디인가는따지는 것

함수 T(n)은 알고리즘의 (비교)연산 횟수를 다항식으로 표현 한 것

보통 T(n)은 다항식으로n^2+2n+2 라고 할 때 최고차항 차수 n^2가 빅오가 된다.

• 의문: 빅오를 구하는 이유는 무엇일까? 실제 알고리즘의 복잡도는 어떻게 구하고 판단해야 하는 가? 그 분석예를 알아 볼 순 없는가?

• 빅오는 비교하는 도구로 생각하지 복잡도 공부는 전공공부를 따로 하자 (알고리즘 과목)

다항식의 차수로 나타내는 이유는 빅오는 X-Y 좌표평면의 그래프와같다

X축은 데이터의 개수, Y축은 시간을 나타내는데 빅오의 O(n^2)는 결국 f(x) = n^2인 이차 방정식 그래프와 같다. 즉 X축(데이터 수)의 증가 에 따라 Y축(시간 or 연산횟수)의 증가를 보여주는 그래프의 형태나 패턴을 나타내는것과 같다

 정리하면‘데이터의 수의 증가’에 따른 ‘ 연산횟수의 증가 형태를 표현 한 것’ 이 빅오이다.

• 질문: 빅오를 알아야 하는 이유는 무엇인가? 성능이겠지... 그리고 성능비교를 위해 근데 위 그림은 다시 공부하자

결과적으로 if구문이나 ‘==’와같은 조건 비교를 적게 써야 한다 (for문과 같은 반복문 포함)

데이터의 수가 많은 경우 순차검색보다 이진 트리 검색의 경우가 더 빠르다   

이중 for문으로 돌려야 하는 경우 순차접근을 사용할 수 있지만 데이터가 순서대로 정렬되어 있고 조건비교를 할 수 있는 경우 이진검색 또는 다른 방법으로 더 빠른 성능 속도를 낼 수 있는지 고민해 볼 수 있어야 한다.

-----------------------------------------------------------------------------------------------------------------------

알고리즘은 아직 논할만큼 충분한 공부를 못했다 (전공책 한번만이라도 처음부터 끝까지 읽어보자... 인터넷 검색은 단편조각만 제공한다) 

참고문서 - 윤성우의 열혈 자료구조

1차 작성 - 2016/03/04 (이글루스에서 옮김)

자료구조는 데이터를 표현하고 저장하는 방법에 대한 설명이다.

프로그램의 정의는 “데이터를 표현하고, 그렇게 표현된 데이터를 처리하는 것”

위에서 말하는 “데이터의 표현” 이란데이터의 저장을 포함하는 것이다.

Dapper 사용 중에 발생한 의문

세가지(단, Dynamic은 키워드로 사용)

Dynamic과 Object와 var는 뭔가 공통점이 있어서 따로 검색

http://blog.naver.com/PostView.nhn?blogId=dotnethelper&logNo=60178694913 (var의 타입변경이 안된다고 적혀있음)

http://www.dotnettricks.com/learn/csharp/differences-between-object-var-and-dynamic-type

https://stackoverflow.com/questions/21080346/difference-between-object-dynamic-and-var

dynamic != object 이다

object를 이해하려면 unboxing/boxing도 이해해야 함

하나 의문점 

- var 는 선언 시점에 타입을 정한다고 하고 정해진 이후에는 타입을 변할 수 없다고 해서 형변환이 안되는가 싶어 테스트 해봤는데 형 변환이 됨

 왜 그런 말이 적혀있는지는 모르겠네..

어쨌든 공통점은 유연한 프로그래밍?? 

이런것이 가능하게 설계된 키워드들이라는 것

바인딩이 느슨하다고 생각하기도 싶지만 var는 컴파일 시점에 이미 타입을 확인하므로 이런점은 다르다

그러면 <T> <dynamic> 이것은 무엇인가?? 

그리고 결과적으로 보면 인터페이스를 사용하는 경우와 Dynamic을 사용하는 경우가 겹칠 수 있다

이유: 상속관계가 아니지만 dynamic을 사용해서 상속된 객체처럼 사용할 수는 있다 (근데 비추다 명확하지가 않을 것 같다)

어쨌든 <T> 는 interface를 사용해서 해당 타입에 대해 사용을 하는 것이라고 볼 수 있고

<dynamic> 도 컴파일 때 타입확인이 아니라 실행 때 확인하며 유연한 제너릭을 제공??? 하는 느낌이다

그렇다면 모든 객체를 받아 올 때 <dynamic>은 만능인가? 끝이 없다.. 

여기서 일단 정리 

- 두개가 공통점이 많으면서 dynamic이 더 한계가 없는(더더 유연한) 느낌이다 

앞의 게시물에서 REST의 개념과 전체적인 특징에 대해서 살펴보았다. 이제는 REST 디자인시 하지 말아야 할 안티 패턴에 대해서 알아보도록 하자.

GET/POST를 이용한 터널링

가장 나쁜 디자인 중 하나가 GET이나 POST를 이용한 터널링이다.

http://myweb/users?method=update&id=terry 이 경우가 전형적인 GET을 이용한 터널링이다. 메서드의 실제 동작은 리소스를 업데이트 하는 내용인데, HTTP PUT을 사용하지 않고, GET에 쿼리 패러미터로 method=update라고 넘겨서, 이 메서드가 수정 메세드임을 명시했다.

대단히 안좋은 디자인인데, HTTP 메서드 사상을 따르지 않았기 때문에, REST라고 부를 수 도 없고, 또한 웹 캐쉬 인프라등도 사용이 불가능하다.

또 많이 사용하는 안좋은예는 POST를 이용한 터널링이다. Insert(Create)성 오퍼러이션이 아닌데도 불구하고, JSON 바디에 오퍼레이션 명을 넘기는 형태인데 예를 들어 특정 사용자 정보를 가지고 오는 API를 아래와 같이 POST를 이용해서 만든 경우이다. 

HTTP POST, http://myweb/users/

{  

   "getuser":{  

          "id":"terry",   

}

}

Self-descriptiveness 속성을 사용하지 않음

앞서 특징에서 설명한 바와 같이 REST의 특성중 하나는 자기 서술성(Self-descriptiveness) 속성으로 REST URI와 메서드 그리고 쉽게 정의된 메시지 포맷에 의해서 쉽게 API를 이해할 수 있는 기능이 되어야 한다. 

특히나 자기 서술성을 깨먹는 가장 대표적인 사례가 앞서 언급한 GET이나 POST를 이용한 터널링을 이용한 구조가 된다.

HTTP Response code를 사용하지 않음

다음으로 많이 하는 실수중의 하나가 Http Response code를 충실하게 따르지 않고, 성공은 200, 실패는 500 과 같이 1~2개의 HTTP response code만 사용하는 경우이다. 심한 경우에는 에러도 HTTP Response code 200으로 정의한후 별도의 에러 메시지를 200 response code와 함께 보내는 경우인데, 이는 REST 디자인 사상에도 어긋남은 물론이고 자기 서술성에도 어긋난다.

출처: http://bcho.tistory.com/953 [조대협의 블로그]

자체 표현 구조(Self-descriptiveness)

REST의 가장 큰 특징 중의 하나는 REST API 자체가 매우 쉬워서 API 메시지 자체만 보고도 API를 이해할 수 있는 Self-descriptiveness 구조를 갖는 다는 것이다. 리소스와 메서드를 이용해서 어떤 메서드에 무슨 행위를 하는지를 알 수 있으며, 또한 메시지 포맷 역시 JSON을 이용해서 직관적으로 이해가 가능한 구조이다. 

대부분의 REST 기반의 OPEN API들이 API 문서를 별도로 제공하고 있지만, 디자인 사상은 최소한의 문서의 도움만으로도 API 자체를 이해할 수 있어야 한다.

개발자에 사랑받는 API 만들기

http://www.mimul.com/pebble/default/2012/08/07/1344315512542.html

1.     기본 URL에는 동사가 아닌 명사를 사용하며, 리소스마다 2개의 기본 URL을 유지하자

-       심플한 것이 가장 보기 좋다

        Ex) /dogs(Collection), /dogs/1234(Element)

2.     HTTP 동사(POST, GET, PUT, DELETE)를 사용해 집합(컬렉션)이나 개별 요소를 오퍼레이션 하자

-       POST(create), GET(read), PUT(update), DELETE(delete)를 명심하자.

-       결국 Resource(collection) / {Key}(element) 형식으로 집합과 요소를 구분하자

3.     복수형 명사와 구체적인 이름을 사용하라.

-       단수보다 복수 형태를 사용하는 편이, 그리고 추상적인 이름보다 구체적인 이름을 사용하는 편이 직관적인 API다.

        Ex) Foursquare : /checkins, GroupOn : /deals, Zappos : /Product

4.     자원 간의 관계를 간단하게 하여 URL 계층이 깊어지는 것을 피하자

-       자원간의 관계, 매개 변수 속성과 같은 복잡한 것은 HTTP 물음표를 뒤에 가지고 가자.

        Ex) GET /owners/5678/dogs, GET /dogs?color=red&state=running&location=park

5.     오류 처리를 명확하게 해라.

-       HTTP 상태코드를 정하고(많아도 안좋음), 개발자들을 위한 오류 메시지 정의, 상세 정보 링크 등을 넣어주면 좋다.

200 - OK
400 - Bad Request
500 - Internal Server Error
201 - Created
304 - Not Modified
404 - Not Found
401 - Unauthorized
403 - Forbidden

-       code, message, more_info 필드를 두어서 결과값을 먼저 파악할 수 있도록 한다.

예) {"status" : "401", "message":"Authenticate","code": 20003, 
 "more info": "http://www.twilio.com/docs/errors/20003"}

6.     버전 관리를 해라.

-       접두사 v로 버전을 지정하고 1계충에 두자.

-       인터페이스로서의 구현이 아님을 강조하기 위해 간단한 정수를 사용하자. 버전 일련번호는 소수점 쓰지 마라.

-       필요시 헤더에 버전을 디자인 할 수 도 있다 (단점은 개발자들이 잊을 수 있다.)

-       Ex) GET /v1/dogs

7.     부분적 응답과 페이징 처리를 하라.

-       리턴해 달라는 필드를 지정하려면(부분 응답) 쉼포로 구분된 목록을 사용하자.

        Ex) /dogs?fields=name,color,location

-       페이징을 할 경우 상대 위치(offset)와 범위(limit)를 사용, 기본 값은 limit=10&offset=0을 사용한다

        Ex) /dogs?limit=25&offset=50

8.     데이터 베이스에 없는 자원에 대한 응답일 경우 동사를 사용하라

-       리소스가 아닌 응답을 전송하는 경우 명사가 아니라 동사를 사용하는 것이 알기 쉽다

-       계산(Calculate), 번역(Translate), 변환(Convert) 등의 경우처럼 알고리즘 계산이나 번역, 환율 변환 등에 요청이 올경우 명사가 아니라 동사를 사용하라.

        Ex) /convert?from=EUR&to=CNY&amount=100

9.     다양한 형식(컨텐트 타입)을 지원하는 경우 도트 형식의 서식으로 하라.

-       JSON과 XML과 같이 API 다른 응답형식을 지원하는 것을 추천한다.

-       기본 형식은 JSON이다.

-       ACCEPT 헤더에 타입을 지정하거나 URL속에 type 매개변수를 사용할 수 있다. 권장 방식은 명사.type(도트 형식의 서식)으로 하는게 낫다.

        Ex) dogs.json, /dogs/1234.json

10.   속성(attribute)의 네이밍은 Javascript의 관습을 따르고 카멜 케이스를 사용하자.

-       기본값으로 JSON을 사용하고, 속성의 이름은 Javascript의 관습을 따른다. 중간 부분에 대문자를 사용(카멜 케이스)

        Ex) "createdAt": 1320296464

11.   검색 팁

-       전체 검색은 동사 “search”와 쿼리 매개 변수”q”를 사용하자

        Ex) /search?q=fluffy+fur

-       범위 한정 검색은 /리소스/리소스 ID/리소스?q=XXX(리소스 ID가 5678 인 주인의 개를 검색) 형태로 한다.

        Ex) /owners/5678/dogs?q=fluffy+fur

-       도트 형식의 서식을 사용하여 검색 결과 형식을 지정하자.

        Ex) /search.xml?q=fluffy+fur

12.   하위 도메인의 독립적인 API 요청 처리는 여러 개를 만들지 말고 통일하라.

- 여러 기능적으로 독립된 url을 여러개 만들지 말고 모든 API 요청을 하나의 API 하위 도메인에 정리하자. api.company.com 같은 것을 사용하는 것이다.

- developers.company.com 같은 개발자 전용 포털을 만들자.

- 사용자가 브라우저에서 API 하위 도메인을 여는 등 요청에 대한 원하는 정보가 없다면 개발자 포털로 리다이렉트 해라.

13.   예외 처리를 위한 팁

-       클라이언트가 HTTP 오류 코드를 차단하는 경우(Adobe Flash 경우), 응답을 클라이언트에서 먹어버림으로 응용 프로그램 개발자가 오류 코드를 차단하는 기회가 없어진다. 그래서 트위터처럼 suppress_response_codes가 있으면 무조건 200으로 리턴하게 한다.

-       클라이언트가 지원하는 HTTP 메소드가 제한되는 경우 URL에서 method형태로 호출하게 한다. 

  예) Create : /dogs?method=post, Read : /dogs, 
 Update : /dogs/1234?method=put&location=park, 
 Delete : /dogs/1234?method=delete

14.   권한 관리(OAuth)는 2.0을 사용하라.

-       OAuth 1.0a보다 2.0을 사용하라. 더 안전하고 웹과 모바일 모두 사용자에게 더 나은 경험을 제공한다.

15.   API 상에서 요청을 구성해보면 아래와 같다

-       AL라는 갈색 개를 생성

POST /dogs
name=Al&furColor=brown
응답
200 OK
{
"dog": {
"id": "1234"
"name": "Al"
"furColor": "brown"
}
}

-       Al의 이름을 Rover로 수정

PUT /dogs/1234
name=Rover
응답
200 OK
{
"dog": {
"id": "1234"
"name": "Rover"
"furColor": "brown"
}
}

-       특정 개에 관라여 조회

GET /dogs/1234
응답
200 OK
{
"dog": {
"id": "1234"
"name": "Rover"
"furColor": "brown"
}
}

-       모든 개에 관해 조회

GET /dogs
응답
200 OK
{
"dogs":
{ "dog": {
"id": "1233"
"name": "Fido"
"furColor": "white"}}
{ "dog": {
"id": "1234"
"name": "Rover"
"furColor": "brown"}}
"_metadata":
[{ "totalCount": 327 "limit"25 "offset": 100}]
}

-       Rover 개 삭제

DELETE / dogs/1234
응답
200 OK

16.   수다 API 지양하자

-       간단한 응용 프로그램을 구축하는데, 여러 번의 서버 API 호출을 해야 하는 수다스러운 API는 지양해라.

-       완전한 RESTful API를 만들고, 필요에 따라 단축키 및 합성 응답을 제공하는 것을 추천한다.

17.   SDK로 API를 보완하라

-       자기 모순없이 표준에 기초하고 있고, 충분히 문서화 되어 있고, 예제도 충분히 있다면 SDK가 필요 없을 수도 있다. 하지만 API 프로바이더는 샘플 코드 라이브러리, 소프트웨어 개발 키트 API를 보충하는 것을 추천한다.

-       도메인 지식에 의해 API가 변경되어서는 안된다. SDK를 통해 API를 보완해라

-       SDK는 낮은 품질, 비효율적인 코드를 줄여준다.

18.   API Facade Pattern을 API 설계에 고려해라.

- 인터페이스와 API구현체 사이의 가상 레이어가 존재한다.

- 구현은 세 가지 기본적인 단계로 구성된다.

- 이상적인 API를 디자인하라 - URL, 요청 파라미터, 응답, 페이로드, 헤더, 쿼리 파라미터 등. API 디자인은 일관되어야 한다.

- 데이터 스텁을 사용하여 디자인을 구현하라. 

  이제 API가 내부 시스템에 연결되기 전에 응용 프로그램 개발자는 API를 사용할 수 있으며, 피드백을 줄 수 있다.

- 퍼사드와 내부 시스템 사이에서 중개자 역할 또는 통합을 한다.

REST 란?

REpresentational State Transfer 의 약자로, 통신 규약이나 표준 또는 스펙이 아니라 분산 하이퍼미디어 시스템을 위한 www 같은 소프트웨어 아키텍처의 한 형식이며 네트워크 상에서 클라이언트와 서버 사이의 통신 방식이다. REST 라는 용어는 2000년 로이필딩(Roy Fielding) 박사의 논문에서 처음 소개되었다.

REST 구성요소

Resource

REST에서 가장 중요한 개념은 바로 유일한 ID를 가지는 Resource가 서버에 존재하고, 클라이언트는 각 Resource의 상태를 조작하기 위해 요청을 보낸다는 것이다. 일반적으로 Resource는 user, friends, group 등과 같은 명사형의 단어이고, HTTP에서 이러한 Resource 를 구별하기 위한 ID는 '/groups/{groupId}/member/101'와 같은 URI이다.

Method

GET, DELETE 등과 같이 Resource를 조작할 수 있는 동사형의 단어를 Method라고 한다. 클라이언트는 URI를 이용해서 Resource를 지정하고 해당 Resource를 조작하기 위해서 Method를 사용한다. HTTP에서는 GET, POST, PUT, DELETE 등의 Method를 제공한다. 

Representation of Resource

클라이언트가 서버로 요청을 보냈을 때, 서버가 응답으로 보내주는 Resource의 상태를 Representation이라고 한다. REST에서 하나의 Resource는 여러 형태의 Representation으로 나타내어 질 수 있다. 예를 들어 xml, json, text, rss 등으로 전달할 수 있다.

URI 구성

- URI는 ‘/groups’, ‘/users’ 등과 같이 직관적으로 어떤 정보를 제공하는지 알 수 있는 단어들로 구성

- URI는 ‘/groups/{groupId}/member/101’와 같이 URI path가 계층적인 구조를 가지도록 구성

- URI의 상위 path는 하위 path의 집합을 의미하는 단어로 구성. 예를 들어 ‘/groups/101/member/12532’의 경우 ‘groups’는 ‘101’ 등의 그룹의 집합이므로 ‘/groups’ 만으로도 그룹 목록이라는 정보를 제공할 수 있는 유효한 URI가 된다.

- CREATE / DESTORY/UPDATE/DELETE 등의 기본 CRUD 처리는 URI에 명시적으로 표현하도록 하여 URI를 보더라도 직관적으로 어떤 기능을 제공하는지 알 수 있도록 명명하도록 한다.

출처: http://naleejang.tistory.com/81 [Nalee의 IT이야기]

1. REST 정의

  - REST는 REpresentational State Transfer의 약자이다. 단순 정의는 그렇고, 실제적인 정의는 아마 ROA(Resource Oriented Architecture)를 따르는 웹 서비스 아키텍처 정도가 될 것이다. 하지만 이것만 봐서도 무엇인지 이해하기는 힘들다. 직관적으로 REST가 무엇이냐, 라고 한다면 "URI와 HTTP 메소드를 이용해 객체화된 서비스에 접근하는것"이라고 하면 될 것 같다. 직관적인 URI를 이용해서 오브젝트의 멤버를 추적하는 것처럼 리소스에 접근하여 HTTP 메소드를 이용해 그것을 조작하는 것이다.


2. REST 특징

  사실 REST는 ROA를 위해 태어났다해도 과언이 아니기 떄문에, ROA의 4가지 속성(Addressability, Connectedness, Statelessness, Homogeneous Interface)과 깊은 연관이 있다.

  - Stateless : Statelessness
  REST의 가장 큰 강점 중 하나이다. 이전, 이후에 대한 직접적인 정보가 필요없이 직관적인 오브젝트에의 접근으로 서비스를 처리한다. 세션정보를 보관할 필요가 없기 때문에, 서비스의 자유도 또한 높아지고 로드밸런싱이라든지 기타 유연한 아키텍처의 적용이 가능하다. 쿠키/세션, 필요없다.

  - URI를 이용 : Addressability
  REST는 모든 유일한 오브젝트에 대해 유일하고 직관적인 URI을 통해 접근하도록 한다. 설명보다는 예를 하나 보는것이 간단한데, 서울대학교의 대학원생들 중 학번이 12345657인 사람의 정보를 얻어오고자 한다면 아래와 같이 표현 가능할것이다.

    www.univinfo.co.kr/seouluniv/undergraduate/1234567

  사실 단순히 저런식으로 표현하는것이 중요한게 아니라, 특정 오브젝트에 접근할때 특정 URI를 통한 접근이 가능한지가 중요하다. 인터넷 메일을 확인할때, 어떤 메일은 특정 주소에서 반드시 특정 링크를 클릭해야지만 메일을 확인할 수 있고, 어떤 메일은 특정 메일을 특정 주소로 접근 가능할 수 있다. 후자가 REST 서비스이다. (당장 지메일의 수신 메일 하나를 클릭한 후 브라우저 주소창에 뜬 주소를 살펴보면 알 수 있을 것이다)

  -  HTTP 메소드를 사용 : Homogeneous Interface
  Homogeneous의 해석에 따라 의미가 갈릴수도 있는데, 동종의 인터페이스만을 사용한다고 보면 된다. 즉, REST는 HTTP에서 제공하는 GET, PUT, POST, DELETE 4개의 메소드(여기에 HEAD나 OPTION을 추가하는 경우도 있다)를 이용해서 서비스를 제공한다. 한편으로는 이것이 REST의 단점이 되기도 하는데, 결국 HTTP 4개 메소드가 DB의 CRUD와 같은 기능을 하기 때문에(C:POST, R:GET, U:PUT, D:DELETE), 이러한 유형으로 분류할 수 없는 작업에 대해서는 어떻게 처리해야 할 지가 조금 모호해지기도 한다. (이메일을 보낸다든지...) 이런 경우 URI를 적절히 정의함으로써 가능하지만, 실제로 서비스별로 URI을 어떻게 정의할 것인가가 REST 설계에 있어 가장 어려운 부분이다.

  - Connectedness
  사실 이부분이 좀 애매하다... 연결성이란것이 서비스내 하나의 리소스가 다른 리소스들간의 관계에 의해 표현되어질 수 있다는 정도로 해석하면 될 것 같다.


3. 장단점

  - 가장 큰 장점은 쉽다는것이다. REST는 통용되는 표준 아닌 표준이 있기는 하지만, 사실 위의 특징들만 잘 지켜서 간결하게 서비스에 접근 가능하다면 그게 REST이다. REST를 지원하는 프레임워크라든지, 언어라든지 이런 도구들이 없어도 얼마든지 구현 가능하다. 이 얘기는 곧 기존의 자원들을 그대로 활용 가능하다는 뜻이 된다. REST 도입을 위해 무언가 굉장히 큰 노력을 기울일 필요가 없다는 것이다.
  반면 단점 역시 명확한데, 표준이 없다는게 단점이다. 각 서비스별로 아키텍처가 다르기 때문에, 이것에 따른 서비스 방안 역시 다를 수 밖에 없다. 그리고 설계나 구현 시에 머리를 써야한다. 단순 CRUD 만으로 표현 불가능한 서비스들이 많기 때문에 고민을 해보고 일을 해야 한다는 뜻이다. 생각없이 뚝딱뚝딱 만들다가는 위에서 얘기한 문제들에 봉착해서 이러지도 저러지도 못하는 수가 생긴다.