GET, POST
HTTP Method
HTTP Method는 클라이언트와 서버 사이에 요청과 응답을 전송하는 방식을 말한다.
주요 메소드
GET 리소스 조회
| POST | 요청 데이터 등록 |
| PUT | 해당 리소스 대체, 해당 리소스가 없다면 생성 (리소스 전체 변경) |
| PATCH | 리소스 부분 변경 |
| DELETE | 리소스 삭제 |
GET 방식
주로 데이터를 읽거나 검색할 때 사용되는 메소드이다. 데이터 조회에 대한 정보는 body에 넣지 않고 쿼리 스트링을 통해 보낸다. (*쿼리 스트링 : URL 끝에 ?뒤에 key1=value1&key2=value2 구조로 쌍을 이루는 요청 파라미터)
GET /members/100?username=inpa&height=200GET방식은 이렇게 url에 담겨가기 때문에 전송할 수 있는 데이터의 크기가 제한적이며, 보안이 필요한 데이터는 데이터가 그대로 url에 노출되기 때문에 적절하지 않다.
데이터 조회에 성공한다며 Body에 데이터 값을 저장하여 성공 응답을 보낸다.
- 캐시가 가능하다. → 같은 데이터를 한 번 더 조회할 경우 저장한 값을 사용하여 POST방식보다 빠르다.
- HTTP 헤더에서 Cache-Control 헤더를 통해 캐시 옵션을 지정할 수 있다.
- 브라우저 히스토리에 남는다.
- 길이 제한이 있으며, 보안상 중요한 정보를 다루면 안된다.
- 요청 정보를 사용자가 쉽게 눈으로 확인할 수 있다.
POST 방식
POST는 주로 새로운 리소스를 생성할 때 사용된다. 리소스를 생성, 변경하기 위해 설계되었기 때문에 GET과는 달리 전송해야할 데이터를 HTTP 메시지의 body에 담아 길이의 제한없이 전송한다. 따라서 POST 요청은 GET 요청과 달리 대용량 데이터를 전송할 수 있다.
데이터가 body에 담겨 전송되지만, post요청도 개발자 도구같은 툴로 요청 내용을 확인할 수 있어서 민감한 데이터의 경우 반드시 암호화를 해줘야 한다. 요청 헤더의 Content-Type에 요청 데이터의 타입을 표시해준다.
- 캐시되지 않는다.
- 브라우저 히스토리에 남지 않는다.
- 데이터 길이에 제한이 없다.
차이점
1. 사용목적
- POST는 서버의 리소스를 새로 생성하거나 업데이트 할 때
- GET은 서버의 리소스에서 데이터를 요청할 때
2. 요청시 body 유무
- POST는 body에 데이터를 담아 보낸다.
- GET은 url 파라미터에 요청하는 데이터를 담아 보내 HTTP 메시지에 body가 없다.
3. 멱등성(idempotent)GET은 리소스를 조회하기에 여러 번 요청하더라도 응답이 동일하기에 멱등이다.
- 반면 POST는 리소스를 생성하거나 업데이트할 때 사용하기에 멱등이 아니다.
- 동일한 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 멱등이라 한다.
CORS(Cross Origin Resource Sharing)
CORS는 출처가 다른 자원들을 공유한다는 뜻으로, 한 출처에 있는 자원에서 다른 출처에 있는 자원에 접근하도록 하는 개념이다. (교차되는 출처 자원들의 공유)
출처가 다른 교차 출처(cross-origin)이란, 아래 세가지 중 한가지라도 다른 경우를 말한다.
출처 : 프로토콜 + 도메인 + 포트번호 (세가지가 모두 일치하면 Same Origin이며, 하나라도 일치하지 않다면 Cross Origin)
브라우저에서는 보안상의 이유로 이 cross-origin http 요청을 제한한다. (default : 거부) 이 cross-origin 요청을 하려면 서버의 동의가 필요한데, 추가 HTTP 헤더를 이용해서 권한을 부여할 수 있고 이를 CORS라고 부른다. 웹 애플리케이션은 리소스가 자신의 출처와 다를 때 교차출처 HTTP 요청을 실행한다.
CORS가 브라우저의 구현 스펙에 포함되는 정책이기에, 브라우저를 통하지 않고 통신을 할 때는(ex. postman) 적용되지 않는다. (postman과 같은 다른 서버에서 api 호출시 잘 동작하다가 브라우저에서 api를 호출했을 때 cors에러 발생)
*SOP(Same Origin Policy) : 다른 출처의 리소스를 사용하는 것을 제한하는 보안방식
기본적인 동작 방식
- 클라이언트에서 HTTP 요청 헤더에 Origin을 담아 전달한다.클라이언트에서 HTTP 프로토콜을 이용하여 서버에 요청을 보내는데, 요청 헤더에 Origin이라는 출처를 담은 필드를 함께 보낸다.
2. 서버는 응답헤더에 Access-Control-Allow-Origin 을 담아 클라이언트로 전달한다. 서버가 해당 요청에 응답을 할 때, 응답헤더에 Access-Control-Allow-Origin 필드를 추가하고, 리소스 접근하는 것이 허용된 출처 url를 담아 보낸다.
3. 클라이언트에서 Origin과 서버가 보내준 Access-Control-Allow-Origin을 비교한다. 응답을 받은 브라우저는 자신이 보낸 요청의 Origin과 서버가 보내준 Access-Control-Allow-Origin을 비교하여 차단여부를 결정한다. (예제는 모두 http://localhost:3000으로 동일하기에 다른 출처의 리소스를 가져올 수 있다) 요청이 다르다면 브라우저에서 이를 막고, cors에러를 뱉어낸다.
CORS는 실제 세 가지의 방식으로 작동한다.
1. Preflight Request
요청을 한번에 보내지 않고, 예비요청과 본 요청으로 나누어 서버로 전송한다. 본 요청 전에 전송하는 예비 요청을 Preflight라 하고, 예비요청에는 OPTIONS 메서드가 사용된다. 브라우저에서 서버에 예비 요청을 보내면, 서버는 어떤 것을 허용하고, 어떤 것을 금지하고 있는지에 대한 정보를 예비 요청에 대한 응답으로 보내준다. 브라우저는 응답을 확인하여 안전하다고 판단되면 다시 본 요청을 보낸다.
2. Simple Request
예비 요청을 생략하고 바로 서버에 본 요청을 보낸 뒤, 서버의 응답에서 Access-Control-Allow-Origin 헤더를 확인해 브라우저가 CORS 정책 위반 여부를 확인하는 방식이다.
3. Credential Request
인증 관련 헤더를 사용하여 다른 출처 간의 통신에서 좀 더 보안을 강화하고 싶을 때 사용하는 방법이다. 클라이언트에서 서버에게 자격 인증정보(Credential)를 실어 요청한다. 자격 인증 정보는 세션 ID가 저장되어 있는 쿠키나 Authorization 헤더에 들어있는 토큰 등을 말한다.
REST와 RESTFUL
REST
REST란 REpresentational State Transfer의 약자로, 대표적인 상태 정도를 의미하며 여기서 상태는 서버가 갖고 있는 리소스의 상태를 뜻한다. 자원을 이름으로 구분해 해당 자원의 상태를 주고받는 것으로, HTTP URI를 통해 자원을 명시하고 HTTP Method를 통해 자원에 대해 CRUD를 적용하는 것을 의미한다.
REST는 통신을 통해 자원의 표현된 상태를 주고받는 것에 대한 가이드라인이다.
구성요소
1. 자원(Resource) - HTTP URI
- 자원을 구별하는 ID는 ‘/groups/:group_id’와 같은 HTTP URI
- Client는 URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청한다
2. 행위(Verb) - HTTP Method
- HTTP 프로토콜의 Method를 사용한다. (GET, POST, PUT, DELETE 와 같은 메서드)
3. 표현(Representation of Resource)
- 클라이언트와 서버가 데이터를 주고받는 형태로 JSON, XML, TEXT등이 있다.
- 주로 JSON과 XML을 통해 데이터를 주고받는다.
REST의 특징
- Server-Client 구조
- 자원이 있는 쪽이 Server, 자원을 요청하는 쪽이 Client
- 역할을 명확히 구분하여 의존성이 낮다.
- Stateless (무상태)
- HTTP 프로토콜이 무상태 프로토콜이기에 REST 또한 무상태성을 갖는다.
- Client의 context를 Server에 저장하지 않는다
- Cacheable (캐시 처리 가능)
- 웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용할 수 있다. → 즉, HTTP가 가진 가장 강력한 특징 중 하나인 캐싱 기능을 적용할 수 있다
- 대량의 요청을 효율적으로 처리 가능
- Uniform Interface (인터페이스 일관성)
- URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행 → 특정 언어나 기술에 종속되지 않고 HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용 가능
REST API
REST의 원리를 따르는 API를 REST API라 한다. 설계시 가장 중요한 규칙은 다음과 같다.
첫 번째, URI는 정보의 자원을 표현해야 한다.
두 번째, 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.
- URI는 정보의 자원을 표현해야 한다. (리소스명은 동사보다는 명사를 사용, 대문자보다 소문자를 사용)
- 마지막에 슬래시(/)를 포함하지 않는다.
- 슬래시는 계층관계를 나타내는데 사용된다
- Ex) http://api.test.com/animals/mammals/whales
- 언더바 대신 하이픈을 사용한다.
- 파일확장자는 URI에 포함하지 않는다.
- 행위(method)는 포함시키지 않는다. ⇒ 자원에 대한 행위는 HTTP Method로 표현
Ex) DELETE http://api.test.com/users/1/posts/1 → (O)
Ex) POST http://api.test.com/users/1/delete-post/1 → (X)
RESTFUL
REST 아키텍쳐를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어로, REST의 원리를 따르는 시스템을 의미한다. REST API의 설계 규칙을 올바르게 지킨 시스템을 RESTFUL하다고 말한다.
Ex) Restful 하지 못한 경우 -> CRUD 기능을 모두 POST로만 처리하는 API