'My Work' 카테고리의 글 목록

1. 개인정보의 처리 목적 (‘https://hankkuu.tistory.com/’이하 ‘Smilegate gamejam’) 은(는) 다음의 목적을 위하여 개인정보를 처리하고 있으며, 다음의 목적 이외의 용도로는 이용하지 않습니다.
- 고객 가입의사 확인, 고객에 대한 서비스 제공에 따른 본인 식별.인증, 회원자격 유지.관리, 물품 또는 서비스 공급에 따른 금액 결제, 물품 또는 서비스의 공급.배송 등

2. 개인정보의 처리 및 보유 기간

① (‘https://hankkuu.tistory.com/’이하 ‘Smilegate gamejam’) 은(는) 정보주체로부터 개인정보를 수집할 때 동의 받은 개인정보 보유․이용기간 또는 법령에 따른 개인정보 보유․이용기간 내에서 개인정보를 처리․보유합니다.

② 구체적인 개인정보 처리 및 보유 기간은 다음과 같습니다.
☞ 아래 예시를 참고하여 개인정보 처리업무와 개인정보 처리업무에 대한 보유기간 및 관련 법령, 근거 등을 기재합니다.
(예시)- 고객 가입 및 관리 : 서비스 이용계약 또는 회원가입 해지시까지, 다만 채권․채무관계 잔존시에는 해당 채권․채무관계 정산시까지
- 전자상거래에서의 계약․청약철회, 대금결제, 재화 등 공급기록 : 5년

3. 정보주체와 법정대리인의 권리·의무 및 그 행사방법 이용자는 개인정보주체로써 다음과 같은 권리를 행사할 수 있습니다.

① 정보주체는 Fire(‘https://hankkuu.tistory.com/’이하 ‘Smilegate gamejam) 에 대해 언제든지 다음 각 호의 개인정보 보호 관련 권리를 행사할 수 있습니다.
1. 개인정보 열람요구
2. 오류 등이 있을 경우 정정 요구
3. 삭제요구
4. 처리정지 요구

4. 처리하는 개인정보의 항목 작성

① ('https://hankkuu.tistory.com/'이하 'Smilegate gamejam')은(는) 다음의 개인정보 항목을 처리하고 있습니다.

1<없음>
- 필수항목 : 없음
- 선택항목 :

5. 개인정보의 파기('Smilegate gamejam')은(는) 원칙적으로 개인정보 처리목적이 달성된 경우에는 지체없이 해당 개인정보를 파기합니다. 파기의 절차, 기한 및 방법은 다음과 같습니다.

-파기절차
이용자가 입력한 정보는 목적 달성 후 별도의 DB에 옮겨져(종이의 경우 별도의 서류) 내부 방침 및 기타 관련 법령에 따라 일정기간 저장된 후 혹은 즉시 파기됩니다. 이 때, DB로 옮겨진 개인정보는 법률에 의한 경우가 아니고서는 다른 목적으로 이용되지 않습니다.

-파기기한
이용자의 개인정보는 개인정보의 보유기간이 경과된 경우에는 보유기간의 종료일로부터 5일 이내에, 개인정보의 처리 목적 달성, 해당 서비스의 폐지, 사업의 종료 등 그 개인정보가 불필요하게 되었을 때에는 개인정보의 처리가 불필요한 것으로 인정되는 날로부터 5일 이내에 그 개인정보를 파기합니다.

6. 개인정보 자동 수집 장치의 설치•운영 및 거부에 관한 사항

Fire 은 정보주체의 이용정보를 저장하고 수시로 불러오는 ‘쿠키’를 사용하지 않습니다.

7. 개인정보 보호책임자 작성

① Fire(‘https://hankkuu.tistory.com/’이하 ‘Smilegate gamejam) 은(는) 개인정보 처리에 관한 업무를 총괄해서 책임지고, 개인정보 처리와 관련한 정보주체의 불만처리 및 피해구제 등을 위하여 아래와 같이 개인정보 보호책임자를 지정하고 있습니다.

▶ 개인정보 보호책임자
성명 :강한규
직책 :작성자
직급 :작성자
연락처 :010-8774-5213, 9inemates@gmail.com,
※ 개인정보 보호 담당부서로 연결됩니다.

▶ 개인정보 보호 담당부서
부서명 :강한규
담당자 :작성자
연락처 :010-8774-5213, 9inemates@gmail.com,
② 정보주체께서는 Fire(‘https://hankkuu.tistory.com/’이하 ‘Smilegate gamejam) 의 서비스(또는 사업)을 이용하시면서 발생한 모든 개인정보 보호 관련 문의, 불만처리, 피해구제 등에 관한 사항을 개인정보 보호책임자 및 담당부서로 문의하실 수 있습니다. Fire(‘https://hankkuu.tistory.com/’이하 ‘Smilegate gamejam) 은(는) 정보주체의 문의에 대해 지체 없이 답변 및 처리해드릴 것입니다.

8. 개인정보 처리방침 변경

①이 개인정보처리방침은 시행일로부터 적용되며, 법령 및 방침에 따른 변경내용의 추가, 삭제 및 정정이 있는 경우에는 변경사항의 시행 7일 전부터 공지사항을 통하여 고지할 것입니다.

9. 개인정보의 안전성 확보 조치 ('Smilegate gamejam')은(는) 개인정보보호법 제29조에 따라 다음과 같이 안전성 확보에 필요한 기술적/관리적 및 물리적 조치를 하고 있습니다.

1. 내부관리계획의 수립 및 시행
개인정보의 안전한 처리를 위하여 내부관리계획을 수립하고 시행하고 있습니다.

2. 개인정보에 대한 접근 제한
개인정보를 처리하는 데이터베이스시스템에 대한 접근권한의 부여,변경,말소를 통하여 개인정보에 대한 접근통제를 위하여 필요한 조치를 하고 있으며 침입차단시스템을 이용하여 외부로부터의 무단 접근을 통제하고 있습니다.

3. 비인가자에 대한 출입 통제
개인정보를 보관하고 있는 물리적 보관 장소를 별도로 두고 이에 대해 출입통제 절차를 수립, 운영하고 있습니다.

저작자표시

'My Work > Blog' 카테고리의 다른 글

Tistory 코드 하이라이트(Syntax Highlighter) 붙이기 (0)	2019.08.13

블로그에 공부 흔적을 남기려면 Code를 넣어야 하는 경우가 생긴다.

해당 부분으로 검색을 하니 SyntaxHighlighter 에 대한 내용이 많았고 이것과 관련해서 삽질한 기록과 문제 상황을 해결한 내용을 기록하기로 한다

일단 Tistory에 Code Syntax Highlighter를 넣기 위해서는 어느 정도 알아야 하는 관련 내용들이 있다.

Javascript/CSS/HTML
Crome 개발자 콘솔 활용법(문제 상황을 해결하기 위해)

위의 내용에 대해서 알아야 이해하면서 적용할 수 있다.

코드 하이라이터를 지원해 주는 것을 보통 소스코드 플러그인이라고 한다 그리고 이것은 javascript opensource 형태로 되었다 먼저 이런 소스코드 플러그인을 선택해야 한다. SyntaxHighlighter 4 를 가장 먼저 발견해서 적용하려고 했으나 대부분의 가이드가 3.0.83 버전으로 되어 있었고 그마저도 제대로 적용이 안돼 다른 것은 어떤 것이 있는지 찾아보게 되었다. 종류와 선택에 대해서는 이기적인 저장소 블로그 내용을 참고했다

Ace Editor (37가지 테마 / 라인 넘버 표시 됨(접기도 가능) / Tap Stop 표시 가능)
highlight.js (89가지 스타일)
SyntacHighlighter 3.0.83 (7가지 테마 / 라인 넘버 표시 됨)

위의 플러그인이 검토되었고 대부분 디자인적으로는 비슷하게 볼 수 있어서 적용하기 간단해 보이는 Ace Editor를 고려하게 되었다. 상대적으로 간단한 특징을 나열하자면

import 시킬 파일이 따로 Tistory 내부에 올리지 않고 CDN만으로 가능
tistory 내부에서 소스 수정이나 추가는 적게
라인 넘버가 표시되고 긴 코드를 보게 될 때는 Scope 영역으로 접힐 수 있으면 좋음

서론은 위와 같고 본론으로 들어가면 간단히 아래 목차와 같다

블로그 관리 홈 -> 스킨 편집 -> HTML 편집
1. ace.js 추가
2. editor setting code 추가(js 작성)
Test page 추가
1. <pre> tag 내 brush(language) 설정
장애 발생 후 개발자 도구 트러블 슈팅

먼저 tistory 내부에서 HTML code 수정이 필요하다

Tistory의 블로그 관리의 꾸미기에 스킨편집 항목이 있고 여기에 들어가면 아래와 같은 화면의 우측에 html 편집을 할 수 있다

- HTML

- CSS

- 파일 업로드

이렇게 3개로 구분되며 기본 설정으로 설정할 경우 HTML만 적용하면 된다

이 링크로 들어가면 https://cdnjs.com/libraries/ace 아래와 같이 CDN을 통한 링크를 가져올 수 있다

HTML에 들어가서 <head>... </head> tag 내부 하단에 아래와 같은 코드를 추가한다

<!doctype html>
<html lang="ko" class="">
<head>
	<meta charset="UTF-8">
	<!--...생략...-->
	<!-- 이렇게 추가 -->
	<script src="https://cdnjs.cloudflare.com/ajax/libs/ace/1.2.3/ace.js"></script>
</head>
<!--...생략...-->

다음으로 가장 중요한 부분인 실제 작동하게 만드는 스크립트 내용을 추가해야 한다

방식 자체는 정규표현식으로 pre 태그 내에 brush를 찾고 그 language로 ace.editor 설정을 하는 것이다.

상황에 따라 jquery 사용 부분을 수정해야 할 수 있다(이 부분을 기존 다른 사람의 가이드만 보고 했을 때 selector 부분이 제대로 작동하지 않아 디버긴을 해야 했다)

중요한 포인트는 내가 설정한 code 영역 즉 <pre>... </pre> 태그를 찾아서 code highliter가 동작하도록 인식시켜야 하는 점이다

아래와 같이 설정한다

<script>
	$(window).on('load', function(){
		/* jQuery 를 이용한 Selector 부분입니다. 
           필요에 따라 아래 부분 특히 pre[class] 부분을 바꺼야 해당 code block을 찾을 수 있을 겁니다*/
		$('pre[class]').each(function(){ 
        try {
			// 언어식별자를 SyntaxHighlight 처럼 "brush: 언어" 형태로 쓸때 식별을 위한 처리부분
			var lang = String($(this).attr("class")).match(/brush\:([ a-zA-Z_]*)\;?/)[1];
			lang = lang.trim().replace(/^js$/i, "javascript");
			// Ace 플러그인 반영 부분
			var editor = ace.edit(this);
			editor.setOptions({
            	maxLines: Infinity, // 줄 전체를 표시 
                // highlightActiveLine: true, // 현재 행에 하이라이트 표시(tomorrow 테마에서 동작)
                // theme: 'ace/theme/tomorrow' // 표시 테마 (아래와 같이 setTheme로도 가능)
			});
			editor.setTheme("ace/theme/monokai");      // 테마설정 부분이에요. 원하는걸로 바꾸세요
			editor.getSession().setMode("ace/mode/"+ lang); // 앞서 "brush:언어" 부분으로 언어 세팅
			editor.setShowInvisibles(true);            // 탭이나 공백, 엔터 기호를 보여줍니다.
			editor.setReadOnly(true);                  // 읽기전용으로 보여줍니다.
			editor.setShowPrintMargin(false);          // 프린트 가이드라인을 보여줍니다 (비활성화)
			editor.session.setUseWorker(false);// 코드에 대한 경고표시 여부(false시에 경고표시 비표시)
			} catch(ex) { console.info (ex) } 
        });
	});
</script>

그 외 옵션은 공식 사이트를 참고할 수 있다 https://ace.c9.io/#nav=howto
테마 종류는 링크에서 확인할 수 있다 https://github.com/ajaxorg/ace/tree/master/lib/ace/theme
사용 가능한 언어(mode)도 확인할 수 있다 https://github.com/ajaxorg/ace/tree/master/lib/ace/mode
미리보기도 가능하다 https://ace.c9.io/tool/mode_creator.html

이제 테스트 페이지를 작성해서 정상적으로 출력이 되는지 확인해본다

테스트 페이지를 작성할 때는 글쓰기 모드를 기본 모드가 아닌 HTML 모드로 변경해서 작성한다

현재 테마에서 완성된 화면은 아래와 같다

자 이제 이렇게 설정하고 한 번에 잘되면 좋겠지만 일단 몇 가지 단점과 불편한 점이 있다.

기본 모드 <-> HTML 모드 전환 간 Code Tag 자동 생성

Tistory의 에디터가 새로 개편되면서 code block 기능이 생기고 기본적인 CodeHighliter가 적용이 된다

즉, 위와 같은 설정을 하지 않아도 기본적인 code 작성이 된다는 것이다. 플러그인으로 설치해서 얻는 이득은 더 많은 기능으로 보이나 현재로서는 더 써봐야 알 것 같다

불편한 점은 에디터가 변경되면서 code block을 자동 인식한다 그래서 위와 같이 HTML 모드에서 작성하고 기본 모드로 돌아가서 나머지 글이나 그림 작업을 마무리하고 HTML 모드로 다시 돌아가거나 기본 모드로 글 작성을 완료하면 <pre>... </pre> 내부에 <code>... </code>가 자동 생성되어 버린다.

이게 자동 생성되면서 기존 플러그인의 기능이 먹히지 않게 되어 코드를 발행할 때마다 해당 부분을 삭제해서 발생하거나 아니면 HTML모드로 글 작성하고 발행까지 완료해야 하는데 그림이나 리스트와 같은 부분을 삽입하려면 기본 모드에서 하는 것이 더 익숙하고 편하다 즉, HTML 모드에서 자동 생기는 Code Tag를 제거해서 플러그인 적용을 완료해야 하는 불편함이 생기게 되었다.

<code> 태그를 삭제하는 스크립트를 작성하거나 뭔가 할 수는 있을 것 같은데 일단 자동생성이 문제가 되는 것이기 때문에 해당 부분을 비활성화할 수 있을지 확인해보거나 최후의 방법으로는 Tistory에서 지원해서는 CodeHighliter인 highlight.js 로 최종 전환하는 것을 고려하게 된다

<> </> 와 같은 xml, html과 같은 markup language를 <pre> 안에서 쓰려면 < > 로 치환

태그 표시와 같은 부분은 HTML 내부에서 독립된 code가 아니라 내부의 HTML로 인식이 되기 때문에 해당 부분을 단순 텍스트로 인식시키는 부분이 필요하다. 이 부분도 불편한 점이고 전반적으로 editor를 자유롭게 쓰려면 HTML에 대한 이해가 있어야 한다. HTML 문서를 만드는데 어려움이 없다면 글 작성도 쉽다

위에 내용을 가는 도중에 문제가 된 부분이 있어 해당 부분에 대한 정리를 추가한다

Jquery 관련
```
<script src="//cdnjs.cloudflare.com/ajax/libs/jquery/3.2.1/jquery.min.js" />
```
the content must be served over HTTPS(개발자 도구 Console 확인)
- 해당 오류는 CSS( <link rel="stylesheet" href="./style.css" /> ) 에서 발생되었는데 tistory의 기본 css 파일이다 여기를 보면 문제가 되는 부분의 import가 http://로 되어 있다 해당 부분을 //로 바꾸면 자동으로 https://로 치환된다
net::ERR_CONNECTION_TIMED_OUT(개발자 도구 console 확인 and 페이지 로딩이 오래 걸림)
- 해당 오류는 위의 http:// 문제를 해결하니 갑자기 페이지 로딩이 오래 걸렸는데 알아보니 cdn 주소가 잘못되어있었다. https://itseminar.tistory.com/5 에서 확인되었고 해당 주소를 아래로 변경해서 import 해주면 된다
  - "https://cdn.rawgit.com/theeluwin/NotoSansKR-Hestia/master/stylesheets/NotoSansKR-Hestia.css''
- Tistory에서는 왜 저런 오류가 나는 상태로 둔 건지는 모르겠지만 웹에 대한 어느 정도 지식이 있으면 해결은 가능하다 지금은 블로그 페이지 로딩 시 발생되는 오류는 없다

크게 Jquery와 내부에서 사용하는 css 파일 관련해서 오류가 있었는데 jquery 부분만 잘 확인해도 플러그인은 잘 작동한다 개발자 콘솔의 오류는 플러그인의 문제를 확인하다가 발견된 부분이다

위의 불편한 점이 있어 ace editor를 계속 쓸지는 한번 고민해 봐야 할 것 같지만 처음이니 한번 써보도록 한다

아래 부분을 염두에 두고 Tistory 블로그를 작성해야 할 것 같다

블로그를 작성하려면 일단 HTML을 잘 알아야 수월한 부분을 이번에 알게 되었다
모바일에서 정상적으로 보이는지도 검토할 부분이다 현재로서는 정상적으로 지원되는 것으로 보인다

참고 링크

이기적인 저장소 - 코드 하이라이트 추천

- Ace Editor 참고

https://blog.kinesis.kr/102?category=648519

https://ispie.tistory.com/23

- Highlighter 참고

https://www.jbfactory.net/12748

https://fraccinospace.tistory.com/entry/highlightjs

https://plorence.kr/446

https://konahn.tistory.com/entry/sh

- SyntaxHighlighter

https://kwonkyo.tistory.com/164

https://sometimes-n.tistory.com/5

랄라 남편

https://keyserbetzman.tistory.com/6

- 오류 관련

SyntaxHighlighter - XRegExp.js 오류

Ace editor - JQuery on 함수 수정

notosans font 수정

- 다른 code plugin

https://hi098123.tistory.com/14 (code-prettify)

https://melony1024.tistory.com/6 (prism.js)

'My Work > Blog' 카테고리의 다른 글

개인정보 처리방침 (0)	2019.08.16

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이 더 한계가 없는(더더 유연한) 느낌이다

'My Work > 파편 조각' 카테고리의 다른 글

RESTful Anti-design (0)	2017.10.18
RESTful API 디자인(네이밍) (0)	2017.10.18
REST란 무엇이냐? (1)	2017.10.18
단위테스트 - TDD (0)	2017.10.18
CI 서버 - 젠킨스 - 지속적통합 (0)	2017.10.18

앞의 게시물에서 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 자체를 이해할 수 있어야 한다.

'My Work > 파편 조각' 카테고리의 다른 글

Dynamic, Template, Generic or Interface (0)	2017.10.18
RESTful API 디자인(네이밍) (0)	2017.10.18
REST란 무엇이냐? (1)	2017.10.18
단위테스트 - TDD (0)	2017.10.18
CI 서버 - 젠킨스 - 지속적통합 (0)	2017.10.18

개발자에 사랑받는 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를 사용할 수 있으며, 피드백을 줄 수 있다.

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

'My Work > 파편 조각' 카테고리의 다른 글

Dynamic, Template, Generic or Interface (0)	2017.10.18
RESTful Anti-design (0)	2017.10.18
REST란 무엇이냐? (1)	2017.10.18
단위테스트 - TDD (0)	2017.10.18
CI 서버 - 젠킨스 - 지속적통합 (0)	2017.10.18

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 만으로 표현 불가능한 서비스들이 많기 때문에 고민을 해보고 일을 해야 한다는 뜻이다. 생각없이 뚝딱뚝딱 만들다가는 위에서 얘기한 문제들에 봉착해서 이러지도 저러지도 못하는 수가 생긴다.

'My Work > 파편 조각' 카테고리의 다른 글

RESTful Anti-design (0)	2017.10.18
RESTful API 디자인(네이밍) (0)	2017.10.18
단위테스트 - TDD (0)	2017.10.18
CI 서버 - 젠킨스 - 지속적통합 (0)	2017.10.18
Binding (0)	2017.10.18

단위테스트를 하는 이유 두가지

1. 개발자가 편하려고?

A. 테스트를 자동화해서 발생할 수 있는 사이드이펙트나 예기치 못한 버그나 상황에 대해 확인 해 볼 수 있다

2. 시나리오 테스트 가능

A. 테스트를 작은 단위로 나누어서 해당 모듈이나 함수마다 테스트를 하므로 중간에 생기는 에러에 대해 확인해 볼 수 있고 시나리오에 따라 반복 테스트를 수월하게 할 수 있다

3. 한 가지 더 적자면 기능을 추가할 때 미리 테스트하면서 어떻게 더 좋은 코드를 붙일 지 고민해 볼 수 있다

즉 개발자는 테스트를 잘 짜는 것이 중요하다

'My Work > 파편 조각' 카테고리의 다른 글

RESTful Anti-design (0)	2017.10.18
RESTful API 디자인(네이밍) (0)	2017.10.18
REST란 무엇이냐? (1)	2017.10.18
CI 서버 - 젠킨스 - 지속적통합 (0)	2017.10.18
Binding (0)	2017.10.18

지속적 통합이라는 개념적 방법론을 실행해주는 자동 빌드 툴

자동빌드의 필요성

- 소스코드의 지속적인 수정이나 기능 추가를 바로바로 반영하기 위해 필요

통합빌드 환경의 필요성

- 실제 운영에 들어가기 전 개발환경의 차이 or 운영환경의 차이 or 기타 물리적인 또는 시스템 구성에서 차이가 있을 수도 있다

- 통합 빌드 환경을 공유하고 사용하면 동일한 환경으로 개발을 진행하거나 테스트 해볼 수 있다

'My Work > 파편 조각' 카테고리의 다른 글

RESTful Anti-design (0)	2017.10.18
RESTful API 디자인(네이밍) (0)	2017.10.18
REST란 무엇이냐? (1)	2017.10.18
단위테스트 - TDD (0)	2017.10.18
Binding (0)	2017.10.18

Binding 은 무었인가?

- 변수나 예약어 등 프로그래밍 언어를 구성하고 있는 여러 것에 속성을 부여하는 것을 바인딩 한다 라고 한단다…

- 속성? 타입? 할당? 뭔가 주입되는 느낌….

바인딩과 할당의 차이는 무엇일까??

어쨌든 바인딩은

1. 연산자에 의해 값이 변할 때

2. 변수 타입을 정하면서 int는 4바이트가 할당된다

3. 변수에 값이 할당될 때

4. 컴파일시 변수의 type이 정해 짐

5. 링커에 의해 외부 프로그램과??? 의 바인딩이 일어난다

6. 각각 변수에 필요한 메모리를 바인딩해준다

7. 프로그램 실행 시 : 프로그램 실행 시 나오는 결과 값을 변수에 바인딩

정적바인딩과 동적바인딩 비교

1. 정적 바인딩 : 컴파일 이전에 바인딩 후 변경이 안됨

Explicit declaration : 타입을 명확히 명시

Implicit declaration : 암시적으로 타입을 명시

- 장점 : 패턴이 정확하다

- 단점 : 다양한 대처가 어렵다

2. 동적 바인딩 : 실행중에 Type이 지속적으로 변화 가능

- 장점 : 유연하다

- 단점 : 고비용 즉, 성능저하가 생길 수 있다

타입의 에러 발견이 어렵다

정리하면

바인딩 된다 ≒ 속성이 부여된다

이런 뜻으로 생각된다 속성을 부여된다니.. 뭐 이런 개소리가 있나 싶다 조금만 더 쉽게 풀어보자..

타입이 결정된다?? 값이 할당된다??

위 그림만 보면 둘다 바인딩이다 즉, 어떻게 보면 속성이 부여된다는 포괄적의미가 맞다

이럴때는 개발적으로 가장 빈도나 가능성이 높아 보이는 하나를 선택해야겠다

바인딩 된다 = 타입이 결정되는 순간 즉 숫자가 할당되면 숫자형으로 바인딩이고 문자가 할당되면 문자형으로 바인딩된다

으로 이해하고 넘어가자

'My Work > 파편 조각' 카테고리의 다른 글

RESTful Anti-design (0)	2017.10.18
RESTful API 디자인(네이밍) (0)	2017.10.18
REST란 무엇이냐? (1)	2017.10.18
단위테스트 - TDD (0)	2017.10.18
CI 서버 - 젠킨스 - 지속적통합 (0)	2017.10.18

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

My Work

개인정보 처리방침

'My Work > Blog' 카테고리의 다른 글

Tistory 코드 하이라이트(Syntax Highlighter) 붙이기

'My Work > Blog' 카테고리의 다른 글

Dynamic, Template, Generic or Interface

'My Work > 파편 조각' 카테고리의 다른 글

RESTful Anti-design

'My Work > 파편 조각' 카테고리의 다른 글

RESTful API 디자인(네이밍)

'My Work > 파편 조각' 카테고리의 다른 글

REST란 무엇이냐?

'My Work > 파편 조각' 카테고리의 다른 글

단위테스트 - TDD

'My Work > 파편 조각' 카테고리의 다른 글

CI 서버 - 젠킨스 - 지속적통합

'My Work > 파편 조각' 카테고리의 다른 글

Binding

'My Work > 파편 조각' 카테고리의 다른 글

+ Recent posts

티스토리툴바