멱등성 : 동일한 요청을 한 번 보내는 것과 여러 번 연속으로 보내는 것이 같은 효과를 지니고, 서버의 상태도 동일하게 남을 때 해당 HTTP 메서드가 멱등성을 가졌다고 한다. 멱등성 메서드에는 통계 기록을 제외하면 어떠한 부수 효과도 존재해서는 안되며, 올바르게 구현한 경우 GET, HEAD, PUT, DELETE 메서드는 멱등성을 가진다. POST 메서드는 그렇지 않다. 모든 안전한 메서드는 멱등성도 가진다.
제일 자주 사용하는 4가지 메소드만 추가 설명을 더 정리하겠다.
1. GET
주로 데이터를 읽거나(Read) 검색(Retrieve)할 때 사용된다. Get 요청이 성공적으로 이루어진다면 json 혹은 xml과 함께 200 (Ok) 응답코드를 리턴한다. 오로지 데이터를 읽을 때만 사용하고 수정할 때는 사용하지 않는다. 데이터를 변경하는 연산에 사용하지 않으므로 당연히 멱등성을 가진다.
요청 시 Body 값과 Content-Type이 비워져있고 주로 쿼리스트링으로 파라미터를 주고받는다. Body를 사용해서 데이터를 전달할 수는 있지만, 지원하지 않는 곳이 많아서 권장하지 않는다.
조회 성공 시 Body 값에 데이터 값을 저장하여 성공 응답을 보낸다.
GET은 캐싱이 가능하여 같은 데이터를 한 번 더 조회할 경우에 저장한 값을 사용하여 조회 속도가 빨라진다.
2. POST
주로 새로운 리소스를 생성하거나 프로세스 처리에 사용된다. 성공적으로 creation을 완료하면 201 (Created) 응답 코드를 반환한다. 요청이 들어올 때마다 리소스가 새로 생성되기에 같은 POST 요청을 여러 번 보냈을 때 항상 같은 결과물이 나오는 것을 보장하지 않으므로 멱등성을 갖지 않는다.
3. PUT
PUT는 리소스를 업데이트 / 생성할 때 사용된다. 즉, 리소스가 있으면 대체하고 없으면 생성한다. 동일한 PUT 요청을 여러 번 호출하면 항상 동일한 결과가 생성되기에 멱등성을 가진다.
4. DELETE
지정된 리소스를 삭제할 때 사용한다. 동일한 요청을 여러 번 보내면 처음 보낸 요청에서 지정 리소스가 삭제되고 이후에는 이미 리소스가 삭제 되고 없어서 에러 코드를 반환할 것이므로 요청을 여러 번 보내도 서버의 상태는 동일하다. 따라서 DELETE 메소드는 멱등성을 가진다.
POST는 요청을 할 때마다 새로운 데이터가 생성되지만, PUT은 사용자가 데이터를 지정하고 수정하는 것이기에 같은 요청을 계속 하더라도 데이터가 계속 생성되지 않고 해당 리소스가 같은 값으로 계속 수정되는 것이므로 멱등성을 가진다.
PUT vs PATCH
위에서 PATCH는 리소스의 일부분만 수정하는 것이라고 했다. 반대로 PUT은 지정한 리소스를 완전히 교체해버린다(덮어쓴다). 따라서 PUT은 멱등하고, PATCH는 멱등하지 않다.
정확하게는, PATCH는 멱등하게 설계할 수도, 멱등이 아니게 설계할 수도 있다.
예를 들어 사용자 정보{이름, 나이} 가 있을 때 이름값만 바꾸게 설정한다면 요청할 때마다 이름이 같은 값으로 바뀌게 되므로 해당 PATCH 요청은 멱등하다.
하지만 한 번 호출할 때마다 나이를 1살씩 더 하는 식으로 설계했다면 요청을 할 때마다 나이가 1살씩 늘어나게 되니 해당 PATCH 요청은 멱등하지 않다.
물론 PUT도 설계하기에 따라 멱등하지 않을 수도 있다. 하지만 위에서 멱등성을 설명할 때도 달아놨듯이 올바르게 구현할 경우 PUT은 멱등해야한다. 즉, PUT은 데이터를 가공하는 것이 아니라 해당 데이터를 덮어써서 바꾸는 것이 태초의 목적인 것이고 PATCH는 그렇지 않기에 올바르게 구현했을 때를 기준으로 PUT은 항상 멱등하고 PATCH는 항상 멱등하다고 말할 수 없다.
브라우저에서는 보안적인 이유로 cross-origin HTTP 요청들을 제한한다. 그래서 cross-origin 요청을 하려면 서버의 동의가 필요하다. 만약 서버가 동의한다면 브라우저에서는 요청을 허락하고, 동의하지 않는다면 브라우저에서 거절한다.
이러한 허락을 구하고 거절하는 메커니즘을 HTTP-header 를 이용해서 가능한데, 이를 CORS(Cross-Origin Resource Sharing) 라고 부릅니다.
동일 출처 정책(Same-Origin Policy, SOP) 란?
브라우저를 거치지 않고 Postman으로 API를 테스트할 때는 잘 동작하다가 브라우저에서 API를 호출하면 CORS policy 오류가 발생할 때가 있다. 그 이유는 브라우저가 동일 출처 정책을 지켜서 다른 출처의 리소스 접근을 금지하기 때문이다. 동일 출처 정책을 지키면 외부 리소스를 가져오지 못해 불편하지만, XSS나 CSRF 등의 보안 취약점을 노린 공격을 방어할 수 있다. 하지만 현실적으로 외부 리소스를 참고하는 것이 꼭 필요하기 때문에 외부 리소스를 가져올 수 있는 방법이 존재해야 하고, 그를 위한 예외 조항이 CORS 이다.
CORS 동작 원리
CORS 동작 방식은 단순 요청 방법(Simple Request)과 예비 요청(Preflight request)을 먼저 보내는 방법 2가지가 있다.
Simple Request - 단순 요청 방법
1. 서버로 요청한다.
2. 서버의 응답이 왔을 때 브라우저가 요청한 Origin과 서버가 응답한 헤더의 Access-Control-Request-Headers의 값을 비교하여 유요한 요청이라면 리소스를 응답한다. 만약 유효하지 않은 요청이라면 브라우저에서 이를 막고 에러가 발생한다.
Simple Request 조건
요청 메서드(method)는 GET, HEAD, POST 중 하나여야 합니다.
Accept, Accept-Language, Content-Language, Content-Type, DPR, Downlink, Save-Data, Viewport-Width, Width를 제외한 헤더를 사용하면 안 됩니다.
Content-Type 헤더는 application/x-www-form-urlencoded, multipart/form-data, text/plain 중 하나를 사용해야 합니다.
첫번째 조건은 어렵지 않지만 두번째, 세번째 조건은 까다로운 조건이다. 두번째 조건은 사용자 인증에 사용되는 Authorization 헤더도 포함되지 않아 까다로운 조건이며, 3번 조건은 많은 REST API들이 Content-Type으로 application/json을 사용하기 때문에 지켜지기 어려운 조건이다.
Preflight request
1. Origin헤더에 현재 요청하는 origin을 담고, Access-Control-Request-Method 헤더에 요청하는 HTTP method를 담고 Access-Control-Request-Headers 요청 시 사용할 헤더를 OPTIONS 메서드로 서버로 요청한다. 이때 내용물은 없이 헤더만 전송한다. 2. 브라우저가 서버에서 응답한 헤더를 보고 유효한 요청인지 확인한다. 만약 유효하지 않은 요청이라면 요청은 중단되고 에러가 발생한다. 만약 유효한 요청이라면 원래 요청으로 보내려던 요청을 다시 요청하여 리소스를 응답 받는다.
GET,POST,PUT,DELETE등의 메서드로 API를 요청했는데, 크롬 개발자 도구의 네트워크 탭에OPTIONS메서드로 요청이 보내졌다면 CORS를 경험한 것이다. Preflight 요청은 실제 리소스를 요청하기 전에OPTIONS라는 메서드를 통해 실제 요청을 전송할지 판단 한다.
OPTIONS메서드로 서버에 예비 요청을 먼저 보내고, 서버는 이 예비 요청에 대한 응답으로Access-Control-Allow-Origin헤더를 포함한 응답을 브라우저에 보낸다. 브라우저는 단순 요청과 동일하게Access-Control-Allow-Origin헤더를 확인해서 CORS 동작을 수행할지 판단한다.
요청 헤더 목록
Origin
Access-Control-Request-Method
preflight요청을 할 때 실제 요청에서 어떤 메서드를 사용할 것인지 서버에게 알리기 위해 사용 된다.
Access-Control-Request-Headers
preflight요청을 할 때 실제 요청에서 어떤 header를 사용할 것인지 서버에게 알리기 위해 사용 된다.
응답 헤더 목록
Access-Control-Allow-Origin
브라우저가 해당 origin이 자원에 접근할 수 있도록 허용합니다. 혹은*은 credentials이 없는 요청에 한해서 모든 origin에서 접근이 가능하도록 허용 한다.
Access-Control-Expose-Headers
브라우저가 액세스할 수 있는 서버 화이트리스트 헤더를 허용 한다.
Access-Control-Max-Age
얼마나 오랫동안preflight요청이 캐싱 될 수 있는지를 나타낸다.
Access-Control-Allow-Credentials
Credentials가 true 일 때 요청에 대한 응답이 노출될 수 있는지를 나타낸다.
preflight요청에 대한 응답의 일부로 사용되는 경우 실제 자격 증명을 사용하여 실제 요청을 수행할 수 있는지를 나타낸다.
간단한 GET 요청은preflight되지 않으므로 자격 증명이 있는 리소스를 요청하면 헤더가 리소스와 함께 반환되지 않으면 브라우저에서 응답을 무시하고 웹 콘텐츠로 반환하지 않는다.
Access-Control-Allow-Methods
preflight요청에 대한 대한 응답으로 허용되는 메서드들을 나타낸다.
Access-Control-Allow-Headers
preflight요청에 대한 대한 응답으로 실제 요청 시 사용할 수 있는 HTTP 헤더를 나타낸다.
