REST?

  • 역사

    • 2000년대 Roy Fielding 박사의 논문에 처음 인용됨.

    Architectural Styles and the Design of Network-based Software Architectures

    • 초간단 요약

      → 웹은 왜 이렇게 성공했고, 왜 이렇게 대규모 시스템이 성립이 된건지 소프트웨어 관점에서 분석하고 하나의 아키텍처 스타일로 정리했는데 이를 REST라 이름 지었다.

    1. 라이브러리를 개발하면서 다른 사람과 작업을 공유하고 싶음. ( 공유의 필요성 )

      • RPC 데몬을 개발. Remote Procedure Call ( 주로 유닉스 사용)
        • 보안 ,리소스 사용 취약함.
    2. 문제점 해결을 하는 동안 프로그래밍 언어, OS 에 상관 없이 해결 하도록 시도.

      • CORBA의 등장!
        • 무겁고 비쌈. ( 2000년대 1억 )
      • RMI - 자바의 RPC 데몬
        • 사내 네트워크에서는 무리 없지만, 방화벽 문제가 생긴다.
        • 기본적 방화벽은 http만 열어줌
    3. 그래서 HTTP를 쓰자!

      • 초기
        • SOAP

          • XML + HTTP 를 결한한 웹 서비스
          • Service-Oriented Architecture → 서비스지향 구조
            • 서비스를 자유자재로 정의할 수 있다 == 복잡하다.
        • ROA의 등장.

          • Resource-Oriented Architecture → 리스소 기반 구조
          • HTTP의 기본 메소드는 CURD와 매핑이 된다

           

    4. 상태값을 전달한다?

      • 결과값에 인터넷에서 발생할 수 있는 상태값을 전달한다.

        → 상태값 코드별로 대응이 가능하다.

        → 상태값 코드만 안다면 누구나 쉽게 이해할 수 있다.

      • State code 일부값

        1. 200 성공
        2. 404 Not Found
        3. 500 내부 서버 오류

      → 결과적으로 REST 구조는 HTTP 프로토콜에서 제공해주는 메커니즘을 그대로 활용한다.

  • REST의 장점?

    1. 쉬운 사용
      1. 서버가 어떻게 돌아가는지 알 필요가 없고 해당 URI와 메소드 자체만 독립적으로 이해하면 됨.
    2. 클라이언트와 서버의 명확한 분리
      1. HTTP의 Stateless 한 특징
      2. 다양한 플랫폼에서 원하는 서비스를 빠르고 쉽개 배포 가능.
    3. HTTP header 와 body의 구조
      1. 헤더에 url 처리 메소드 명시
      2. body에는 필요한 데이터로 구성되어 다양한 언어를 사용할 수 있다.
    4. 웹 친화적
      • 방화벽 문제를 해결 가능
    5. 캐싱
    6. 개발자 직관적
    7. 컨텐츠 협상
      • 클라이언트가 영문 → 서버가 한글이여도 컨텐츠 협상을 통해 다르게 응답할 수 있다.
  • REST의 단점

    1. 메소드의 형태가 제한적이다.
    2. 표준이 없다
      • 관리의 어려움과 공식화된 API 디자인 가이드가 없다.

구성 요소

  1. Resource

    → 유일한 ID를 가지는 Resource가 서버에 존재.

    — id는 일반적으로 url을 사용한다.

    → 클라이언트 → 서버 자원의 상태를 조작하기 위해 요청을 보냄.

  2. Method

    → 자원을 조작할 수 있는 것.

    • Get

      → 서버에게 Resource를 보내도록 요청.

      → 사용

      1. 자원을 읽음.
    • Post

      → 서버에 데이터를 보내기 위함.

      → 사용 :

      1. 업데이트
      2. Put과의 차이는 put은 서버 자원에 데이터를 저장 시기키 위함.
      3. Post는 데이터를 보내기 위한 용도
    • Put

      → 자원의 전체 내용을 교체할 때

      → 사용 :

      1. 모든 파라미터 (데이터의) 자원이 교체 되어야한다.
    • Delete

      → 자원을 삭제를 하도록 요청

      → 서버가 무시할 수 있다.

      → 항상 보장 되지 않음.

    • Head

      → Get과 동일하지만 서버에서 body를 주지 않음

      → 사용

      1. 자원이 존재하는지 확인
      2. 리소스 수정 되어 있는지 확인 ( context-length )
    • Connect

      → http connecct 방법.

      → http 프록시 서버에 tcp 연결을 원하는 대상으로 전달하도록 요청.

      → 사용 :

      1. 최초의 연결만 http 연결이고 이후에는 tcp 사용하여 연결함.
    • Options

      → 타겟 서버의 지원 가능한 method 확인.

    • Trace

      → 클라이언트 → Request Packet → (방화벽, Proxy Server, Gateway) → 서버

      → 이 진행 상황중 packet의 변조가 일어날 수 있다.

      → 원본 데이터와 서버 도착 데이터를 서버 응답 body를 통해 확인할 수 있다.

      → 사용

      1. 보안 취약점으로 인해 사용 중지 권장.
    • Patch

      → put과 유사하지만 부분을 바꿀 때 사용한다.

      → 사용 :

      1. 전체를 바꾸는 게 아니라 부분을 바꿀 때 사용.
  3. Representation of Resource

    • 자원을 이름으로 구분하여 해당 자원의 상태를 주고 받는 모든 것.
  4. URI

    • Uniform Resource Identifier
    • 자원의 주소를 명시한다.

 

RESTFUL

REST의 제약에 따르고 있고, REST다운 것을 말한다.

필요 최소한으로 지켜야할 5가지 규칙

  1. API의 ENDPOINT 가 오직 한개인가?

    • 오직 한개의 URL로 fix
    • 실제 자원에 대한 정보는 body에 전송 하도록 구현
  2. 모든 방식은 POST 방식으로만 요청하는가?

    • POST , PUT, GET, DELETE 메소드를 사용해라
    • 잘한 것
      • POST /url
      • PUT /url
      • GET /url
      • DELETE /url
    • 잘못된 것
      • POST /url?cmd=insert
      • POST /url?cmd=update
      • POST /url?cmd=select
      • POST /url?cmd=delete
  3. 응답에 대한 메타데이터를 BODY에 포함하는가?

    • 메타 데이터는 Header
    • Body는 오로지 리소스의 순수한데이터만!
  4. URL에 동사(VERB)가 포함되어 있는가?

    • URL의 이름은 주소값 → 명사적인 특징을 가진다
    • 동사적 틍직을 가지면 혼돈이 올 수 있다.
  5. URL에 RPC 호출 메서드 명령이 있는가?

    • URL에 PRC (Remote Procedure Call )사용하지 마라.

템플릿 엔진?

 

템플릿을 읽어 엔진의 문법과 설정에 따라서 파일을 HTML 형식으로 변환시키는 모듈.

 

 

EJS

 

1. 설치

 

npm install ejs

 

2. 사용

 

var express = require('express');
var app = express();

app.set('view engine', 'ejs');

 

Model -> View 로 데이터 전달.

 

Model에서 사용한 변수명 그대로 사용하면 된다.

..
<body>
	<h1> <%=title %> </h1>
    <ul>
    	<% for(var temp in data){ %>
        <li>
        	<%= data[temp].title %>
        </li>
        <% } %>
    </ul>
</body>
...

 

 

참고

https://ejs.co/#docs

 

EJS -- Embedded JavaScript templates

Simple syntax JavaScript code in simple, straightforward scriptlet tags. Just write JavaScript that emits the HTML you want, and get the job done!

ejs.co

 

'html > js' 카테고리의 다른 글

[SPA] Single-page Application, SPA 장단점  (0) 2019.12.30
[Javascript] html 안에 html 추가하기  (0) 2019.10.24

Seo란?

-> 검색 엔진 최적화.

 

Robots.txt

- 검색 엔진이 어느 부분을 크롤링할지 안 할지 정함.

- Robots.txt를 읽는데 오류가 나면, 사이트를 크롤링하지 않음.

 

Sitemap.xml

- 크롤러가 콘텐츠를 검색하고 색인을 생성하는데 사용할 수 있는 사이트 url

 

일반적인 실수들

- 데스크톱과 모바일이 탐색 결과가 다른 경우.

- js 기반 , html 에 없는 항목

    - google은 js 를 크롤링 하지만 아직은 부족.

- 기본 페이지로 연결되는 link 

    - link는 크롤러가 새 페이지로 가는 경로.

 

커스텀 404 페이지

- 기본 404페이지가 아닌, 사이트 검색 또는 연락처 정보 추가.

-> 사이트에서 이탈 할 가능성이 줄어듬.

 

Google SEO 기본 개념

 

Title 태그

- 사용자와 검색 엔진에게 특정 페이지의 주제를 알려줌.

     - 검색 결과에 제목으로 반영.

- 참고 할만한 것

     - 페이지의 콘텐츠를 정확하고 명확하게 설명해야 함.

     - 페이지마다 고유해야 함.

     - 간결 및 내용 포함 제목 작성.

 

Description 태그

- 각 페이지의 요약 정보를 보여줌.

     - 검색 결과에 작은 글씨로 설명이 보여줌.

- 참고할만한 것

     - 너무 짧지도 길지도 않게, 1~2개 짧은 단락으로 설명해야 함.

     - 같은 문구를 반복적으로 사용하지 않을 것

     - 페이지의 내용을 정확하게 설명.

     - 각 페이지마다 내용에 맞는 고유한 설명

 

Url 구조 간결!

- 사용자, 크롤러를 위해 url을 간단하고 명료하게 만들어라.

     - 사이트 정리가 쉬움.

     - 검색 엔진이 문서를 크롤링하기도 쉬움.

     - 검색 결과에 url이 보인다.

- 참고할만한 것

     - url에 단어를 사용해라.

     - 단순한 디렉터리 구조를 만들어라.

 

사이트 내에서 이동하기 쉽게 만들어라.

- 사용자, 크롤러에게 사이트 내의 이동은 매우 매우 중요.

- 메인 화면에서 다른 자세한 콘텐츠가 있는 페이지로 이동을 편리하게 해라.

    - 메인 페이지 -> 관련 카테고리 목록 -> 특정 주제

- 참고할만한 것

    - 자연스러운 계층 구조.

 

사용자가 url을 실수하는 경우

- 커스텀 404 페이지

- 상위 페이지로 이동.

 

실제 사용자, 검색 엔진 두 종류의 사이트 맵 준비.

 

<a> 태그

- 이 텍스트는 어떠한 페이지 설명이다.라고 알려줌.

- 참고 사항

    - 이동하는 페이지의 내용을 함축하는 텍스트

    - 간결하게 적어라

    - 링크는 눈에 띄기 쉽게 만들어라.

 

<img> 태그

- alt 속성

     - 이미지를 표시할 수 없는 경우 대체 텍스트

     - 스크린 리더를 사용할 경우 읽어 준다. 

     - 구글 이미지 검색에 도움을 준다.

- 참고 사항

     - 간결한, 설명적인 파일 이름 및 alt 텍스트.

     - 이미지를 링크로 사용할 때 alt 텍스트 제공

     - 이미지 사이트맵 제공하기.

 

 

 

참고 사이트

https://static.googleusercontent.com/media/www.google.com/ko//intl/ko/webmasters/docs/search-engine-optimization-starter-guide-ko.pdf

불러오는 중입니다...

 

- IE , Firefox , Chrome , Safari , Opera 등 여러 브라우저 존재.

- 같은 기본값을 사용하지 않음.

 

- 동일한 css 적용 했을 경우에도 다른 결과물이 보일 수 있음.

-> body, p, table 등 간격이 미세하게 다름.

 

 

- 2019 reset.css 

https://gist.github.com/DavidWells/18e73022e723037a50d6

 

reset.css

GitHub Gist: instantly share code, notes, and snippets.

gist.github.com

 

 

- 참고

https://aboooks.tistory.com/115

 

[html/css]브라우저 기본값의 초기화 리셋(reset.css)의 개념

[html/css]브라우저 기본값의 초기화 리셋(reset.css)의 개념 브라우저는 HTML언어를 번역해서 보여주는 기능을 한다고 했는데요, HTML 기초 (markup, 브라우저 종류/ XHTML, XML, HTML5, DHTML 차이) 대표적인 브..

aboooks.tistory.com

 

'html' 카테고리의 다른 글

[REST/RESTFUL] 개념 간단 정리  (0) 2019.11.08
[Google SEO] 구글 SEO 기초중의 기초  (0) 2019.10.31
[HTML5] 시맨틱태그 정리  (0) 2019.10.24
  • <article>

    • Section 태그의 하위 개념.
    • 독자적으로 이해할 수 있는 콘텐츠.
    • 웹 사이트의 나머지 부분과 독립적으로 읽을 수 있어야한다.
    • Ex) 포럼 게시물, 블로그 포스트, 신문 기사
  • <aside>

    • 본문 전체 내용과 직접적인 연관성이 없는 분리된 내용을 담을 때 사용.
    • Ex) 사이드바에 사용되며, 배너 광고, 위젯등이 있다.
  • <details>

    • 사용자가 보거나 숨길수 있는 추가적인 세부 정보
    • Ex) 더보기, 상세보기
  • <figcaption>, <figure>

    • 이미지에 시작적 설명을 추가하는 곳.

<figure> 
	<img src="" alt ="img1">
	<figcaption>
    	Img1 is cool
	</figcaption> 
</figure>
  • <footer>

    • 문서 또는 섹션의 바닥 글을 지정한다.
    • 포함된 요소에 대한 정보를 포함해야함.
    • 여러개가 있을 수도 있다.
    • Ex) 작성자, 저작권 정보, 이용 약관 링크, 연락처 정보등이 포함됨.
  • <footer>

    • 문서 또는 섹션의 바닥 글을 지정한다.
    • 포함된 요소에 대한 정보를 포함해야함.
    • 여러개가 있을 수도 있다.
    • Ex) 작성자, 저작권 정보, 이용 약관 링크, 연락처 정보등이 포함됨.
  • <header>

    • 문서 또는 섹션 헤더를 지정한다.
    • 한 문서에 여러 요소가 있을 수도 있다.
    • Ex) 사이트 로고, 글로벌 링크(회원가입, 언어셋), 소개 등..
  • <main>

    • 문서의 주가 되는 컨텐츠 정의
  • <mark>

    • 참조나 하이라이트 표시가 필요로하는 문자를 정의
  • <nav>

    • 탐색 링크의 집합을 정의한다.
  • <section>

    • 일반적으로 제목이 있는 주제별 콘텐츠 그룹.
    • 문서의 section을 의미한다.
    • 내부에 header, footer 가 올 수 있는데, 이 때 사용 되는 태그는 해당 영역에 대한 제목, 꼬리말로 사용된다
    • Html5 시맨틱 태그의 주요한 부분
  • <summary>

    • details에 대한 보이는 요소를 정의.
  • <time>

    • 날짜 / 시간 정의

사전 준비

1. Jquery

 

예시 코드

<script src="http://code.jquery.com/jquery-latest.js"></script> 
<script>
	$(document).ready(function(){
    	$("document id or className").load("your html dir");
	});
</script>
<head>
...
	<script src="http://code.jquery.com/jquery-latest.js"></script> 
    <script>
    	$(document).ready(function(){
    		$(".header").load("header.html");
		});
    </script>
...
</head>
<body>
...
	<div class="header">
    </div>
...
</body>

Slack 세팅

 

1.Add more apps

2. incoming webhooks 검색 -> install

3. 메세지 전송할 채널 선택

 

4. 메세지 구조

curl -X POST --data-urlencode "payload={\"channel\": \"#general\", \"username\": \"webhookbot\", \"text\": \"This is posted to #general and comes from a bot named webhookbot.\", \"icon_emoji\": \":ghost:\"}" http://여기에 채널 주소가 들어가게됩니다.

 

태그 설명

username : 보내는 사람 이름

text : 보낼 내용

icon_emohi : 이모티콘 사용

 

5. 터미널 아무 경로에서 작성

 

깃 세팅

 

1. Repositories - Settings - Webhooks - Add webhook 등록

  • Payload URL : Webhook Node.js 주소
  • Content type : 파싱할 타입 -> Json 사용
  • Secret : Webhook 에서 사용할 인증 비밀번호  (Webhook 서버 비밀번호 코드와 동일해야 한다.)

Node.js 서버 세팅

1. 프로젝트 구조

  • hook.sh : git 명령어를 사용해 pull을 실행해주는 스크립트 쉘 파일.
  • index.js : git webhook으로 전달 받은 json을 파싱해주고, 시크릿 키를 비교 진행. 맞다면 hook.sh 파일을 실행.

 

참고

1. https://github.com/velopert/nodejs-github-webhook/blob/master/README.md

 

velopert/nodejs-github-webhook

Github Webhook server built with Node.js. Contribute to velopert/nodejs-github-webhook development by creating an account on GitHub.

github.com

 

+ Recent posts