내가 수집 할 수있는 것에는 세 가지 범주가 있습니다.

1. 결코 사용 GET및 사용POST
2. 결코 사용 POST및 사용GET
3. 어떤 것을 사용하든 상관 없습니다.

이 세 가지 경우를 가정 한 것이 맞습니까? 그렇다면 각 사례의 예는 무엇입니까?

브라우저의 주소 표시 줄에서 작업을 수행 POST할 수 없으므로 작성 (아이러니를 알고 있음), 편집 및 삭제와 같은 파괴적인 작업에 사용하십시오 POST. GET사람이 행동을 할 수있는 것이 안전 할 때 사용하십시오 . 따라서 다음과 같은 URL :

http://myblog.org/admin/posts/delete/357

단순히 항목을 삭제하는 것이 아니라 확인 페이지로 이동해야합니다. 이런 식으로 사고를 피하는 것이 훨씬 쉽습니다.

POST또한 GET정보를 URL에 고정하지 않기 때문에 보다 안전 합니다. 그리고 사용 GET은 AS method암호 나 기타 민감한 정보를 수집하는 HTML 양식이 가장 좋은 생각이 아니다.

마지막 메모 : POST보다 많은 양의 정보를 전송할 수 있습니다 GET. 'POST'에는 전송 된 데이터에 대한 크기 제한이 없으며 'GET'은 2048 자로 제한됩니다.

간단히

• 사용 GET에 대한 safe andidempotent요청
• 사용 POST에 대한 neither safe nor idempotent요청

세부 사항 각각에 적절한 장소가 있습니다. RESTful 원칙을 따르지 않더라도 REST 및 리소스 지향 접근 방식이 어떻게 작동 하는지를 통해 많은 것을 얻을 수 있습니다.

RESTful 응용 프로그램 use GETs은 모두 작업에 적합합니다 safe and idempotent.

safe작업은 않은 작업입니다 not change the data요청했다.

idempotent작업은 결과가되는 하나입니다 be the same당신이 그것을 요청하는 횟수에 상관없이.

안전한 작동을 위해 GET이 사용되기 때문에 자동으로 dem 등원 (imdempotent)이되는 것은 당연 합니다. 일반적으로 GET은 리소스 (예 : 질문 및 스택 오버플로에 대한 관련 답변) 또는 리소스 모음을 검색하는 데 사용됩니다.

RESTful 앱은의 PUTs작업에 사용 합니다 not safe but idempotent.

질문은 GET과 POST에 관한 것이지만 잠시 후에 POST로 돌아갑니다.

일반적으로 PUT은 리소스를 편집하는 데 사용됩니다 (예 : 스택 오버플로에서 질문 또는 답변 편집).

A는 POST어떤 작업에 사용된다 neither safe or idempotent.

일반적으로 POST는 새로운 SO 질문 생성과 같은 새로운 리소스를 생성하는 데 사용됩니다 (일부 디자인에서는 PUT도 사용됨).

POST를 두 번 실행하면 두 가지 새로운 질문이 생깁니다.

DELETE 작업도 있지만 거기에 남겨 둘 수 있다고 생각합니다. :)

토론

실제적으로 현대 웹 브라우저는 일반적으로 GET 및 POST 만 안정적으로 지원합니다 (자바 스크립트 호출을 통해 이러한 모든 작업을 수행 할 수 있지만 양식에 데이터를 입력하고 제출을 누르면 일반적으로 두 가지 옵션이 있습니다). RESTful 애플리케이션에서 POST는 종종 PUT 및 DELETE 호출을 제공하기 위해 대체됩니다.

그러나 RESTful 원칙을 따르지 않더라도 정보 검색 /보기에 GET을 사용하고 정보 작성 / 편집에 POST를 사용하는 측면에서 생각하는 것이 유용 할 수 있습니다.

데이터를 변경하는 작업에 GET을 사용해서는 안됩니다. 검색 엔진이 악의적 인 op에 대한 링크를 크롤링하거나 클라이언트의 북마크를 크롤링하면 큰 문제가 발생할 수 있습니다.

반복되는 요청이 마음에 들지 않으면 GET을 사용하십시오 (상태가 변경되지 않음).

조작으로 시스템 상태가 변경되면 POST를 사용하십시오.

짧은 버전

GET : 일반적으로 제출 된 검색 요청 또는 사용자가 정확한 페이지를 다시 가져올 수있는 요청에 사용됩니다.

GET의 장점 :

• URL을 안전하게 북마크 할 수 있습니다.
• 페이지를 안전하게 다시로드 할 수 있습니다.

GET의 단점 :

• 변수는 URL을 통해 이름-값 쌍으로 전달됩니다. (보안 위험)
• 전달할 수있는 제한된 수의 변수. (브라우저 기반. 예를 들어 Internet Explorer는 2,048 자로 제한됩니다. )

POST : 데이터를 사용하여 데이터베이스를 변경하거나 다른 사람이 북마크하고 싶지 않은 페이지를 더 높은 보안 요청에 사용합니다.

POST의 장점 :

• 이름-값 쌍은 URL에 표시되지 않습니다. (보안 + = 1)
• POST를 통해 무제한의 이름-값 쌍을 전달할 수 있습니다. 참고.

POST의 단점 :

• POST 데이터를 사용한 페이지는 책갈피가 될 수 없습니다. (원하는 경우)

더 긴 버전

하이퍼 텍스트 전송 프로토콜 에서 직접 -HTTP / 1.1 :

9.3 GET

GET 메소드는 Request-URI에 의해 식별되는 모든 정보 (엔티티 형태)를 검색하는 것을 의미합니다. Request-URI가 데이터 생성 프로세스를 참조하는 경우, 해당 텍스트가 프로세스의 출력이 아닌 한, 프로세스의 소스 텍스트가 아닌 응답의 엔티티로 리턴되는 생성 된 데이터입니다.

요청 메시지에 If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match 또는 If-Range 헤더 필드가 포함 된 경우 GET 메소드의 의미는 "조건부 GET"으로 변경됩니다. 조건부 GET 메소드는 조건부 헤더 필드에 설명 된 상황에서만 엔티티를 전송하도록 요청합니다. 조건부 GET 방법은 여러 요청을 요구하거나 클라이언트가 이미 보유한 데이터를 전송하지 않고도 캐시 된 엔터티를 새로 고치도록하여 불필요한 네트워크 사용을 줄이려고합니다.

요청 메시지에 Range 헤더 필드가 포함 된 경우 GET 메소드의 의미가 "부분 GET"으로 변경됩니다. 14.35 절에서 설명한 것처럼 부분 GET은 엔티티의 일부만 전송하도록 요청합니다. 부분 GET 방법은 클라이언트가 이미 보유한 데이터를 전송하지 않고 부분 검색된 엔티티를 완료 할 수 있도록하여 불필요한 네트워크 사용을 줄 이도록 고안되었습니다.

GET 요청에 대한 응답은 섹션 13에 설명 된 HTTP 캐싱 요구 사항을 충족하는 경우에만 캐시 가능합니다.

양식에 사용될 때 보안 고려 사항은 섹션 15.1.3을 참조하십시오.

9.5 POST

POST 메소드는 오리진 서버가 요청에 포함 된 엔티티를 요청 라인의 Request-URI에 의해 식별 된 자원의 새로운 하위 항목으로 승인하도록 요청하는 데 사용됩니다. POST는 균일 한 방법으로 다음 기능을 처리 할 수 ​​있도록 설계되었습니다.

• 기존 자원의 주석

• 게시판, 뉴스 그룹, 메일 링리스트 또는 유사한 기사 그룹에 메시지 게시;

• 양식 제출 결과와 같은 데이터 블록을 데이터 처리 프로세스에 제공하는 단계;

• 추가 작업을 통해 데이터베이스를 확장합니다.

POST 방법으로 수행되는 실제 기능은 서버에 의해 결정되며 일반적으로 Request-URI에 따라 다릅니다. 게시 된 엔티티는 파일이 포함 된 디렉토리에 종속되거나 뉴스 기사가 게시 된 뉴스 그룹에 종속되거나 레코드가 데이터베이스에 종속 된 것과 동일한 방식으로 해당 URI에 종속됩니다.

POST 메소드에 의해 수행 된 조치로 인해 URI로 식별 할 수있는 자원이 생성되지 않을 수 있습니다. 이 경우 응답에 결과를 설명하는 엔터티가 포함되어 있는지 여부에 따라 200 (OK) 또는 204 (No Content)가 적절한 응답 상태입니다.

가장 중요한 것은 GET과 POST 의 의미 입니다.

• GET은 서버 로부터 정보 를 얻는 데 사용되어야 합니다.
• POST는 일부 정보 를 서버 에 전송하는 데 사용해야 합니다.

그 후, 주목할 수있는 몇 가지 사항 :

• GET을 사용하면 사용자는 브라우저에서 "뒤로"단추를 사용하고 페이지를 책갈피에 추가 할 수 있습니다.
• GET으로 전달할 수있는 매개 변수의 크기에는 제한이 있습니다 (실수하지 않은 경우 일부 Internet Explorer 버전의 경우 2KB) . 한도는 POST의 경우 훨씬 많으며 일반적으로 서버 구성에 따라 다릅니다.

어쨌든, 우리가 GET없이 "살아"낼 수 없다고 생각합니다. 매일 쿼리 문자열에서 매개 변수와 함께 사용하는 URL의 수를 생각하십시오-GET이 없으면 작동하지 않습니다. ;-)

많은 웹 브라우저의 길이 제약 조건 차이 외에도 의미상의 차이도 있습니다. GET은 서버 상태를 변경하지 않는 읽기 전용 작업이므로 "안전"해야합니다. POST는 일반적으로 상태를 변경하고 다시 제출시 경고를 표시합니다. 검색 엔진의 웹 크롤러는 GET을 만들 수 있지만 POST를 수행해서는 안됩니다.

상태를 변경하지 않고 데이터를 읽으려면 GET을 사용하고 서버에서 상태를 업데이트하려면 POST를 사용하십시오.

제 일반적인 규칙은 상태를 변경하지 않을 서버에 요청을 할 때 Get을 사용하는 것입니다. 게시물은 상태를 변경하는 서버에 대한 요청을 위해 예약되어 있습니다.

한 가지 실질적인 차이점은 브라우저와 웹 서버가 URL에 존재할 수있는 문자 수에 제한이 있다는 것입니다. 응용 프로그램마다 다르지만 textarea양식에 s 가 있으면 칠 수 있습니다 .

GET을 사용하는 또 다른 문제-검색 엔진 및 기타 자동 시스템에 의해 색인이 생성됩니다. Google은 한 번보고있는 페이지에 링크를 미리 가져 오는 제품을 가지고 있었으므로 해당 링크를 클릭하면로드 속도가 더 빠릅니다. 사람들이 전체 사이트를 잃어버린 링크와 같은 사이트 에 큰 혼란을 초래 delete.php?id=1했습니다.

URL이 페이지 상태를 반영하도록하려면 GET을 사용하십시오. 여기에 표시된 것과 같이 동적으로 생성 된 페이지를 보는 데 유용합니다. "응답 게시"버튼을 클릭 할 때와 같이 데이터를 제출하기 위해 양식에 POST를 사용해야합니다. 또한 경로 다음에 매개 변수 문자열을 생성하지 않으므로보다 깔끔한 URL을 생성합니다.

GET은 순전히 URL이므로 웹 브라우저에서 캐시 할 수 있으며 일관되게 생성 된 이미지와 같은 작업에 더 적합 할 수 있습니다. (만료 시간 설정)

Gravatar 페이지의 한 가지 예 : http://www.gravatar.com/avatar/4c3be63a4c2f539b013787725dfce802?d=monsterid

GET은 성능이 약간 향상 될 수 있습니다. 일부 웹 서버는 처리기를 호출하기 전에 POST 내용을 임시 파일에 씁니다.

고려해야 할 또 다른 사항은 크기 제한입니다. 브라우저는 더 많은 것을 지원할 수 있지만 GET은 URL 크기로 표준에 의해 1024 바이트로 제한됩니다.

보다 많은 데이터를 전송하면 더 나은 브라우저 호환성을 위해 POST를 사용해야합니다.

다른 포스터가 썼 듯이, 그 한도 미만은 문제가된다. URL의 어떤 것도 역사와 같은 브루어 UI의 다른 부분으로 이어질 수있다.

당신이 할 수있는 일은 없습니다. 요점은 당신이하지 않을 것입니다 생각 하는 HTTP GET의 서버 상태를 수정할 수 있습니다. HTTP 프록시는 HTTP GET이 상태를 수정하지 않기 때문에 사용자가 HTTP GET을 한 번 또는 1000 번 호출하는지 여부는 차이가 없다고 가정합니다. 이 정보를 사용하여 캐시 된 버전의 첫 번째 HTTP GET을 리턴하는 것이 안전하다고 가정합니다. HTTP 사양을 위반하면 HTTP 클라이언트 및 프록시가 손상 될 위험이 있습니다. 하지마 :)

이것은 REST의 개념과 웹 사용 방법에 관한 것입니다. 훌륭한 팟 캐스트가 있습니다소프트웨어 엔지니어링 라디오 Get 및 Post 사용에 대해 심도있게 이야기합니다.

Get은 서버에서 데이터를 가져 오는 데 사용되며 업데이트 작업이 필요하지 않습니다. 아이디어는 동일한 GET 요청을 반복해서 사용하고 동일한 정보를 반환해야한다는 것입니다. URL은 다른 정보를 찾을 수있는 주소와 같은 다른 시스템 및 사람들에게 쉽게 전송 될 수 있도록하기 위해 쿼리 문자열에 정보를 가져옵니다.

Post는 정보를 서버로 푸시하거나 서버에게 정보를 제공하여 작업을 수행하기 위해 (적어도 웹이 기반으로하는 REST 아키텍처에 의해) 사용됩니다. 예를 들면 다음과 같습니다.이 데이터를 업데이트하고이 레코드를 만듭니다.

1.3 HTTP 선택을위한 빠른 점검 목록 GET또는POST

다음과 같은 경우 GET을 사용하십시오.

    The interaction is more like a question (i.e., it is a safe operation such as a query, read operation, or lookup).

다음과 같은 경우 POST를 사용하십시오.

    The interaction is more like an order, or
    The interaction changes the state of the resource in a way that the user would perceive (e.g., a subscription to a service), or
    The user be held accountable for the results of the interaction.

소스 .

나는 get을 사용하여 문제를 보지 못하지만 쿼리 문자열에 물건을 보관하는 것이 합리적 인 간단한 일에 사용합니다.

delete.php?id=5페이지를 삭제하는 GET과 같이 상태를 업데이트하는 데 사용하면 매우 위험합니다. 사람들은 Google의 웹 액셀러레이터가 페이지에서 URL 프리 페치를 시작했을 때 모든 '삭제'링크를 치고 사람들의 데이터를 지 웠음을 알았습니다. 검색 엔진 스파이더에서도 동일한 일이 발생할 수 있습니다.

POST는 큰 데이터를 이동할 수 있지만 GET은 할 수 없습니다.

그러나 일반적으로 웹 사이트 / 웹 응용 프로그램이 잘 작동하기를 원한다면 GET의 단점이 아니라 관습입니다.

http://www.w3.org/2001/tag/doc/whenToUseGet.html 을 보십시오

에서 RFC 2616 :

9.3 GET
GET 방법은 Request-URI에 의해 식별되는 모든 정보 (엔티티 형태)를 검색하는 것을 의미한다. Request-URI가 데이터 생성 프로세스를 참조하는 경우, 해당 텍스트가 프로세스의 출력이 아닌 한, 프로세스의 소스 텍스트가 아닌 응답의 엔티티로 리턴되는 생성 된 데이터입니다.

9.5 POST
POST 메소드는 요청 서버에서 Request-URI에 의해 식별 된 자원의 새로운 하위 항목으로 요청에 포함 된 엔티티를 오리진 서버가 수락하도록 요청하는 데 사용됩니다. POST는 균일 한 방법으로 다음 기능을 처리 할 수 ​​있도록 설계되었습니다.

• 기존 자원의 주석
• 게시판, 뉴스 그룹, 메일 링리스트 또는 유사한 기사 그룹에 메시지 게시;
• 양식 제출 결과와 같은 데이터 블록을 데이터 처리 프로세스에 제공하는 단계;
• 추가 작업을 통해 데이터베이스를 확장합니다.

POST 방법으로 수행되는 실제 기능은 서버에 의해 결정되며 일반적으로 Request-URI에 따라 다릅니다. 게시 된 엔티티는 파일이 포함 된 디렉토리에 종속되거나 뉴스 기사가 게시 된 뉴스 그룹에 종속되거나 레코드가 데이터베이스에 종속 된 것과 동일한 방식으로 해당 URI에 종속됩니다.

POST 메소드에 의해 수행 된 조치로 인해 URI로 식별 할 수있는 자원이 생성되지 않을 수 있습니다. 이 경우 응답에 결과를 설명하는 엔터티가 포함되어 있는지 여부에 따라 200 (OK) 또는 204 (No Content)가 적절한 응답 상태입니다.

사람들이 QueryString을 보지 못하게하거나 QueryString이 커질 때 POST를 사용합니다. 또한 파일 업로드에는 POST가 필요합니다.

그래도 GET을 사용하는 데 문제가 보이지 않지만 QueryString에 물건을 보관하는 것이 합리적인 간단한 용도로 사용합니다.

GET을 사용하면 POST가 작동하지 않는 특정 페이지로의 링크도 가능합니다.

원래 의도는 GET을 사용하여 데이터를 다시 가져오고 POST를 사용하는 것이 었습니다. 내가 사용하는 경험의 규칙은 서버로 무엇이든 다시 보내면 POST를 사용한다는 것입니다. 데이터를 얻기 위해 URL을 호출하는 경우 GET을 사용합니다.

Wikipedia에서 HTTP에 관한 기사를 읽으십시오 . 프로토콜이 무엇이며 어떤 역할을하는지 설명합니다.

가져 오기

지정된 자원의 표현을 요청합니다. 웹 응용 프로그램에서 작업을 수행하는 데 사용하는 등 부작용을 일으키는 작업에는 GET을 사용해서는 안됩니다. 그 이유 중 하나는 로봇이나 크롤러가 임의로 GET을 사용할 수 있기 때문에 요청으로 인한 부작용을 고려할 필요가 없기 때문입니다.

과

POST 처리 될 데이터 (예 : HTML 양식)를 식별 된 자원으로 제출합니다. 데이터는 요청 본문에 포함됩니다. 이로 인해 새 리소스가 생성되거나 기존 리소스가 업데이트되거나 두 가지 모두가 발생할 수 있습니다.

W3C에는 URIs, Addressability 및 HTTP GET 및 POST 사용 이라는 문서가 있으며 언제 무엇을 사용해야하는지 설명합니다. 인용

1.3 HTTP GET 또는 POST 선택을위한 빠른 점검 목록

• 다음과 같은 경우 GET을 사용하십시오.
  • 상호 작용은 질문과 유사합니다 (예 : 쿼리, 읽기 작업 또는 조회와 같은 안전한 작업).

과

• 다음과 같은 경우 POST를 사용하십시오.
  • 상호 작용은 주문과 비슷하거나
  • 상호 작용은 사용자가인지하는 방식 (예를 들어, 서비스에 대한 가입)으로 자원의 상태를 변경하거나, o 사용자는 상호 작용의 결과에 대해 책임을진다.

그러나 HTTP GET 또는 POST를 사용하기로 최종 결정하기 전에 중요한 데이터에 대한 고려 사항 및 실제 고려 사항도 고려해야합니다.

실용적인 예는 HTML 양식을 제출할 때마다 있습니다. 양식 작업에 대해 게시 또는 가져 오기 를 지정합니다 . PHP는 이에 따라 $ _GET 및 $ _POST를 채 웁니다.

PHP에서 POST데이터 제한은 보통에 의해 설정됩니다 php.ini. GET내가 생각하는 서버 / 브라우저 설정에 의해 제한됩니다-일반적으로 255바이트 주위 .

에서 w3schools.com :

HTTP 란 무엇입니까?

HTTP (Hypertext Transfer Protocol)는 클라이언트와 서버 간의 통신을 가능하게하도록 설계되었습니다.

HTTP는 클라이언트와 서버 간의 요청-응답 프로토콜로 작동합니다.

웹 브라우저는 클라이언트 일 수 있으며 웹 사이트를 호스팅하는 컴퓨터의 응용 프로그램은 서버 일 수 있습니다.

예 : 클라이언트 (브라우저)가 서버에 HTTP 요청을 제출합니다. 그런 다음 서버는 클라이언트에 응답을 반환합니다. 응답에는 요청에 대한 상태 정보가 포함되어 있으며 요청 된 컨텐츠가 포함되어있을 수도 있습니다.

두 가지 HTTP 요청 방법 : GET 및 POST

클라이언트와 서버 간의 요청-응답에 일반적으로 사용되는 두 가지 방법은 GET과 POST입니다.

GET – 지정된 자원에서 데이터를 요청합니다. POST – 지정된 자원으로 처리 할 데이터를 제출합니다.

여기서 우리는 주요 차이점을 구별합니다.

POST GET PUT DELETE의 단순 버전

• GET 사용-ID 또는 이름을 기반으로하는 데이터 목록과 같은 리소스를 얻으려는 경우
• 서버에 데이터를 보내려면 POST를 사용하십시오. POST는 중량이 많이 드는 작업입니다. 업데이트를 위해 POST 대신 PUT을 사용해야합니다. POST는 새로운 리소스를 생성합니다.
• PUT 사용-때

한 가지 중요한 것은 제출 한 모든 내용이 GETURL을 통해 노출된다는 것입니다. 두 번째로 Ceejayoz가 말했듯이 URL의 문자에는 제한이 있습니다.

또 다른 차이점은 POST에는 일반적으로 두 개의 HTTP 작업이 필요하지만 GET에는 하나만 필요하다는 것입니다.

편집 : 일반적인 프로그래밍 패턴을 명확히해야합니다. 일반적으로 똑바로 HTML 웹 페이지로 POST에 응답하는 것은 여러 가지 이유로 의심스러운 디자인입니다. 그 중 하나는 "이 양식을 다시 제출해야합니까?" 뒤로 버튼을 누를 때

다른 사람들이 대답했듯이 get으로 URL 크기에 제한이 있으며 파일은 게시물로만 제출할 수 있습니다.

게시물로 가져 오기 및 수행 작업으로 데이터베이스에 항목을 추가 할 수 있다고 덧붙이고 싶습니다 . 스크립트가 게시물이나 가져 오기를 받으면 작성자가 원하는대로 할 수 있습니다. 나는 이해의 부족이 책이 선택한 단어 나 당신이 그것을 읽는 방법에서 비롯된 것이라고 생각합니다.

스크립트 작성자 는 게시물을 사용하여 데이터베이스를 변경하고 get은 정보 검색에만 사용해야합니다.

스크립팅 언어는 요청에 액세스 할 수있는 많은 방법을 제공했습니다. 예를 들어, PHP를 사용하면 $_REQUEST게시물이나 가져 오기를 검색 할 수 있습니다. 하나는보다 구체적인 찬성이를 방지해야 $_GET하거나 $_POST.

웹 프로그래밍에는 해석의 여지가 훨씬 많습니다. 무엇을 해야 하고 무엇을 할 수 있는지 가 있지만, 어느 쪽이 더 좋은지 종종 논쟁의 대상이됩니다. 운 좋게도이 경우 모호성이 없습니다. 당신은 해야 데이터를 변경하는 게시물을 사용, 당신은 해야 정보를 검색 할 수 사용합니다.

Gorgapor는 mod_rewrite여전히 사용 GET합니다. 친숙한 URL을 GET쿼리 문자열 이있는 URL로 변환 할 수 있습니다 .

HTTP Post 데이터에는 데이터 양에 대해 지정된 제한이 없으며 브라우저마다 GET에 대한 제한이 다릅니다. RFC 2068 상태는 다음과 같습니다.

일부 오래된 클라이언트 또는 프록시 구현은 이러한 길이를 제대로 지원하지 않을 수 있으므로 서버는 255 바이트를 초과하는 URI 길이에 따라주의해야합니다.

특히 당신은 그들이 사용하는 것에 대한 올바른 HTTP 구성을해야합니다. HTTP GET에는 부작용이 없어야하며 HTTP 프록시 등에 의해 안전하게 새로 고쳐지고 저장 될 수 있습니다.

url 리소스에 대해 데이터를 제출하려는 경우 HTTP POST가 사용됩니다.

HTTP GET을 사용하는 일반적인 예는 검색에 있습니다. 예 : Search? Query = my + query HTTP POST를 사용하는 일반적인 예는 온라인 양식에 피드백을 제출하는 것입니다.