REST API - PUT DELETE POST GET을 사용하는 이유는 무엇입니까?

그래서 REST API를 만드는 방법에 대한 기사를 살펴 보았습니다. 그리고 그들 중 일부는 POST 요청을 PUT DELETE POST와 같이 모든 유형의 HTTP 요청을 사용할 것을 제안합니다. 예를 들어 index.php를 만들고 API를 다음과 같이 작성합니다.

$method = $_SERVER['REQUEST_METHOD'];
$request = split("/", substr(@$_SERVER['PATH_INFO'], 1));

switch ($method) {
  case 'PUT':
    ....some put action.... 
    break;
  case 'POST':
    ....some post action.... 
    break;
  case 'GET':
    ....some get action.... 
    break;
  case 'DELETE':
    ....some delete action.... 
    break;
}

OK, 부여 - 웹 서비스에 대해서는 잘 모릅니다 (아직). 하지만 일반 POST 또는 GET (메소드 이름과 모든 매개 변수가 포함됨)을 통해 JSON 객체를 받아들이고 JSON으로도 응답하는 것이 더 쉽지 않을까요? 우리는 PHP의 json_encode ()와 json_decode ()를 통해 쉽게 직렬화 / 역 직렬화 할 수 있고 다른 HTTP 요청 메소드를 다룰 필요없이 데이터로 원하는 모든 작업을 수행 할 수 있습니다.

내가 놓친 게 있니?

업데이트 1 :

Ok - 다양한 API를 파고 XML-RPC, JSON-RPC, SOAP, REST에 대해 많은 것을 배운 후에이 API 유형이 옳았다는 결론을 얻었습니다. 실제로 스택 교환은 사이트에서이 접근 방식을 사용하고 있으며 스택 Exchange API를 수행하고있는 사람을 알고 있다고 생각합니다.

해결법

==============================
1.REpresentational State Transfer의 개념은 가능한 한 가장 간단한 방법으로 데이터에 액세스하는 것이 아닙니다.

REpresentational State Transfer의 개념은 가능한 한 가장 간단한 방법으로 데이터에 액세스하는 것이 아닙니다.

JSON에 액세스하기위한 게시물 요청을 사용하는 것이 좋습니다. 이는 데이터에 액세스 / 조작하기위한 완벽한 방법입니다.

REST는 의미있는 데이터 액세스 방법입니다. REST에서 요청을 볼 때 데이터에서 발생한 일을 즉시 확인해야합니다.

예 :
```
GET: /cars/make/chevrolet
```
사치스러운 자동차 목록을 반환 할 가능성이 높습니다. 좋은 REST API는 정보를 인코딩해야하는 형식을 접근 자 (accessor)가 결정할 수있게 해주는? output = json 또는? output = html과 같은 쿼리 문자열에 일부 출력 옵션을 통합 할 수도 있습니다.

합리적으로 데이터 유형을 REST API에 통합하는 방법에 대해 생각한 후에 데이터 유형을 명시 적으로 지정하는 가장 좋은 방법은 .js, .json, .html과 같은 이미 존재하는 파일 확장자를 사용하는 것이라고 결론을지었습니다. , 또는 .xml. 누락 된 파일 확장명은 기본값 (예 : JSON)의 형식으로 기본 설정됩니다. 지원되지 않는 파일 확장명은 501 Not Implemented 상태 코드를 반환 할 수 있습니다.

다른 예시:
```
POST: /cars/
{ make:chevrolet, model:malibu, colors:[red, green, blue, grey] }
```
관련 색상으로 DB에 새로운 쇠비름 말리부를 만들 것입니다. 아마 REST API가 데이터베이스 구조와 직접적으로 관련 될 필요는 없다고 말할 수 있습니다. 진정한 데이터를 보호하기 위해 그냥 마스킹 인터페이스 일뿐입니다 (데이터베이스 구조에 대한 접근 자 및 변경자와 같음).

이제 우리는 멱등 원 문제로 나아갈 필요가 있습니다. 일반적으로 REST는 HTTP를 통해 CRUD를 구현합니다. HTTP는 요청에 대해 GET, PUT, POST 및 DELETE를 사용합니다.

REST를 매우 단순하게 구현하면 다음 CRUD 매핑을 사용할 수 있습니다.
```
Create -> Post
Read   -> Get
Update -> Put
Delete -> Delete
```
이 구현에는 문제가 있습니다. Post는 비 멱등식 메소드로 정의됩니다. 즉, 동일한 Post 메소드를 계속 호출하면 다른 서버 상태가 발생합니다. Get, Put 및 Delete는 멱등수입니다. 즉 여러 번 호출하면 서버 상태가 동일해야합니다.

이는 다음과 같은 요청을 의미합니다.
```
Delete: /cars/oldest
```
실제로 다음과 같이 구현 될 수 있습니다.
```
Post: /cars/oldest?action=delete
```
이므로
```
Delete: /cars/id/123456
```
한 번만 호출하거나 1000 번 호출하면 동일한 서버 상태가됩니다.

가장 오래된 항목을 제거하는 가장 좋은 방법은 다음을 요청하는 것입니다.
```
Get: /cars/oldest
```
결과 데이터의 ID를 사용하여 삭제 요청을하십시오.
```
Delete: /cars/id/[oldest id]
```
이 방법의 문제점은 / oldest가 요청 된 시점과 삭제 된 시점 사이에 다른 / cars 항목이 추가 된 경우입니다.
==============================
2.이는 보안 및 유지 관리 문제입니다.

이는 보안 및 유지 관리 문제입니다.

가능할 때마다 잠재적 취약성을 제한하기 위해 GET 및 HEAD와 같은 '안전한'(단방향) 방법을 사용해야합니다.

가능한 경우, GET, HEAD, PUT 및 DELETE와 같은 '멱등 원 (idempotent)'메소드를 사용해야합니다.이 메소드는 부작용이 없으므로 오류가 발생하기 쉽고 제어하기가 쉽습니다.

출처
==============================
3.요컨대, REST는 동사보다 명사를 강조합니다. API가 복잡해지면 더 많은 명령을 사용하지 않고 더 많은 것을 추가 할 수 있습니다.

요컨대, REST는 동사보다 명사를 강조합니다. API가 복잡해지면 더 많은 명령을 사용하지 않고 더 많은 것을 추가 할 수 있습니다.
==============================
4.너는 물었다 :

너는 물었다 :

REST에 관한 Wikipedia에서 :

필자가 보았던 것에서는 기존 HTTP 동사의 사용을 극대화하고 가능한 한 강력하고 자명 한 서비스를위한 URL 스키마를 디자인함으로써 대개이를 수행 할 수 있다고 생각합니다.

사용자 정의 데이터 프로토콜 (SOAP 또는 JSON과 같은 표준 프로토콜 위에 구축 된 경우에도)은 권장하지 않으며 REST 이데올로기에 가장 잘 부합하도록 최소화해야합니다.

작업중인 실제 오브젝트는 어떤 형식이든 적용 할 수 있습니다. 사용자가 원하는 리소스 (쿼리, 상태 관리 / 변이, 삭제)를 수행하기 위해 최대한 많은 HTTP를 다시 사용하는 것이 좋습니다.

너는 물었다 :

REST와 URI 구문 / HTTP 동사 자체에 대해 알아야 할 것이 많습니다. 예를 들어, 일부 동사는 멱등수이고 다른 동사는 그렇지 않습니다. 나는 당신의 질문에 이것에 관해 무엇이라도 보지 않았다. 그래서 나는 그것에 들어가기 위해 시험하는 것을 괴롭히지 않았다. 다른 답변과 위키피디아 모두 좋은 정보가 많습니다.

또한 진정으로 안정적인 API를 사용하는 경우 활용할 수있는 HTTP 위에 구축 된 다양한 네트워크 기술에 대해 알아야 할 것이 많습니다. 인증부터 시작하겠습니다.
==============================
5.확장 기능을 사용하여 데이터 유형을 정의하는 것과 관련이 있습니다. 나는 MailChimp API가 그것을하고 있다는 것을 알았지 만, 나는 이것이 좋은 생각이라고 생각하지 않는다.

확장 기능을 사용하여 데이터 유형을 정의하는 것과 관련이 있습니다. 나는 MailChimp API가 그것을하고 있다는 것을 알았지 만, 나는 이것이 좋은 생각이라고 생각하지 않는다.
```
GET /zzz/cars.json/1

GET /zzz/cars.xml/1
```
좋은 생각처럼 들리지만, HTTP 헤더를 사용하면 "오래된"접근 방식이 더 좋습니다.
```
GET /xxx/cars/1
Accept: application/json
```
또한 HTTP 헤더는 교차 데이터 형식 통신에 훨씬 더 좋습니다 (누군가가 필요하다면)
```
POST /zzz/cars
Content-Type: application/xml     <--- indicates we sent XML to server
Accept: application/json          <--- indicates we want get data back in JSON format  
```
==============================
6.예. ;-)

예. ;-)

이 현상은 균일 한 인터페이스 제약 때문에 존재합니다. REST는 바퀴를 다시 발명하는 대신 기존 표준을 사용하는 것을 좋아합니다. HTTP 표준은 이미 확장 성이 입증되었습니다 (웹은 잠시 작동합니다). 왜 우리는 깨지지 않은 것을 고쳐야합니까?!

참고 : 클라이언트와 서비스를 분리하려는 경우 통일 된 인터페이스 제약 조건이 중요합니다. 클래스를 서로 분리하기 위해 클래스의 인터페이스를 정의하는 것과 비슷합니다. Ofc. 여기에서 유니폼 인터페이스는 HTTP, MIME 유형, URI, RDF, 링크 된 데이터 보캐브, 히드라 보캐 등의 표준으로 구성됩니다.
==============================
7.좋은 의미는 프로그래밍에서 중요합니다.

좋은 의미는 프로그래밍에서 중요합니다.

GET / POST 외에도 더 많은 방법을 사용하면 코드의 가독성이 높아져 유지 관리가 쉬워 지므로 도움이됩니다.

왜?

GET이 API에서 데이터를 검색한다는 것을 알고 있기 때문입니다. POST가 시스템에 새 데이터를 추가한다는 것을 알고 있습니다. PUT이 업데이트를한다는 것을 알고 있습니다. DELETE는 행 등을 삭제합니다.

일반적으로 내 RESTful 웹 서비스를 구조화하여 메서드와 동일한 함수라는 이름의 콜백을 만듭니다.

나는 PHP를 사용하므로 function_exists (나는 그것이 호출된다고 생각한다)를 사용한다. 함수가 존재하지 않으면, 나는 405를 던진다 (허용되지 않는 메소드).
==============================
8.Bill Venners : "REST가 실패한 이유"라는 블로그 게시물에서 GET, POST, PUT 및 DELETE와 같은 네 가지 HTTP 동사가 필요하며 브라우저 공급 업체 만 GET 및 POST 만한다고 애도했습니다. "왜 우리 모두가 동사는 왜 GET과 POST가 충분하지 않습니까?

Bill Venners : "REST가 실패한 이유"라는 블로그 게시물에서 GET, POST, PUT 및 DELETE와 같은 네 가지 HTTP 동사가 필요하며 브라우저 공급 업체 만 GET 및 POST 만한다고 애도했습니다. "왜 우리 모두가 동사는 왜 GET과 POST가 충분하지 않습니까?

Elliotte Rusty Harold : HTTP에는 GET, POST, PUT 및 DELETE의 네 가지 기본 메소드가 있습니다. GET은 대부분 사용됩니다. 그것은 안전하고 부작용을 일으키지 않는 모든 것에 사용됩니다. GET은 북마크되고, 캐싱되고, 링크되고, 프록시 서버를 통과 할 수 있습니다. 이것은 매우 강력한 작업이며 매우 유용한 작업입니다.

대조적으로 POST는 아마도 가장 강력한 작업입니다. 그것은 무엇이든 할 수 있습니다. 일어날 수있는 것에 관해서는 한계가 없기 때문에 그 결과로 매우주의해야합니다. 너는 그것을 북마크하지 않는다. 당신은 그것을 캐쉬하지 않습니다. 미리 가져 오지 마십시오. 사용자에게 묻지 않고 POST로 아무 것도하지 않습니다. 이걸하고 싶니? 사용자가 버튼을 누르면 일부 내용을 POST 할 수 있습니다. 그러나 페이지의 모든 버튼을 보지 않고 무작위로 누르기 시작합니다. 반대로 브라우저는 페이지의 모든 링크를보고 미리 가져 오거나 다음에 가장 많이 따르는 것으로 생각되는 것을 미리 가져올 수 있습니다. 사실 일부 브라우저와 Firefox 확장 기능 및 기타 여러 도구가 한 지점 또는 다른 지점에서이를 시도했습니다.

PUT과 DELETE는 GET과 POST 중간에 있습니다. PUT 또는 DELETE와 POST의 차이점은 PUT과 DELETE가 * 멱등 (idempotent) 인 반면 POST는 그렇지 않다는 것입니다. 필요한 경우 PUT 및 DELETE를 반복 할 수 있습니다. 새 페이지를 사이트에 업로드하려고한다고 가정 해 보겠습니다. http://www.example.com/foo.html에서 새 페이지를 만들고 싶은 경우 콘텐츠를 입력하고 URL에 붙여 넣으십시오. 서버는 사용자가 제공 한 URL에 해당 페이지를 작성합니다. 자, 네트워크 연결이 끊어지는 것을 생각해 봅시다. 당신은 확실하지 않습니다, 요청이 통과했는지 안 했습니까? 어쩌면 네트워크가 느릴 수도 있습니다. 어쩌면 프록시 서버 문제가있을 수 있습니다. 따라서 원하는만큼 반복하여 다시 시도해도 무방합니다. 동일한 문서를 동일한 URL에 10 번 붙여 넣는 것은 한 번만 넣는 것과 다를 바가 없습니다. DELETE도 마찬가지입니다. 열 번을 삭제할 수 있으며, 한번 삭제하면됩니다.

반대로 POST는 매번 다른 일이 발생할 수 있습니다. 구매 버튼을 눌러 온라인 상점에서 체크 아웃한다고 가정 해보십시오. POST 요청을 다시 보내면 장바구니에있는 모든 것을 다시 구매할 수 있습니다. 다시 보내면 세 번 샀습니다. 이것이 브라우저가 명백한 사용자 동의없이 POST 작업을 반복하는 것에 매우주의해야하는 이유입니다. POST를 사용하면 두 번 수행하면 두 가지 일이 발생할 수 있고 세 번 수행하면 세 가지가 발생할 수 있기 때문에 브라우저에 대한주의가 필요합니다. PUT과 DELETE를 사용하면 0 요청과 1 요청간에 큰 차이가 있지만 하나의 요청과 10 사이에는 차이가 없습니다.

자세한 내용은 URL을 방문하십시오. http://www.artima.com/lejava/articles/why_put_and_delete.html

최신 정보:

멱등 함수 멱등 원 (idempotent) HTTP 메소드는 다른 결과없이 여러 번 호출 할 수있는 HTTP 메소드입니다. 메서드가 한 번만 호출되거나 10 번 이상 호출되는 것은 중요하지 않습니다. 결과는 동일해야합니다. 다시 말하지만, 이것은 자원 자체가 아니라 결과에만 적용됩니다. 이 정보가 (현재) 자원 표현에서 공유되지 않으면 업데이트 타임 스탬프와 같이 조작 할 수 있습니다.

다음 예제를 고려하십시오.

첫 번째 예제는 멱등수입니다.이 문을 몇 번이나 실행하더라도 a는 항상 4입니다. 두 번째 예제는 멱등수가 아닙니다. 이 10 번 실행하면 5 번 실행했을 때와 다른 결과가 발생합니다. 두 예제 모두 a의 값을 변경하기 때문에 둘 다 안전하지 않은 방법입니다.

from https://stackoverflow.com/questions/4573305/rest-api-why-use-put-delete-post-get by cc-by-sa and MIT license

'PHP' 카테고리의 다른 글

echo와 print는 PHP에서 어떻게 다릅니 까? [복제] (0)	2018.09.20
어떻게 PHP에서 file_get_contents () 함수의 경고를 처리 할 수 있습니까? (0)	2018.09.20
PHP에서 ob_start ()의 사용법은 무엇입니까? (0)	2018.09.20
명령 줄에서 사용하는 php.ini 파일을 찾는 방법은 무엇입니까? (0)	2018.09.20
PHP 경로를 찾지 못하는 오류 포함 (0)	2018.09.20

복붙노트

REST API - PUT DELETE POST GET을 사용하는 이유는 무엇입니까?

REST API - PUT DELETE POST GET을 사용하는 이유는 무엇입니까?

해결법

1.REpresentational State Transfer의 개념은 가능한 한 가장 간단한 방법으로 데이터에 액세스하는 것이 아닙니다.

2.이는 보안 및 유지 관리 문제입니다.

3.요컨대, REST는 동사보다 명사를 강조합니다. API가 복잡해지면 더 많은 명령을 사용하지 않고 더 많은 것을 추가 할 수 있습니다.

4.너는 물었다 :

5.확장 기능을 사용하여 데이터 유형을 정의하는 것과 관련이 있습니다. 나는 MailChimp API가 그것을하고 있다는 것을 알았지 만, 나는 이것이 좋은 생각이라고 생각하지 않는다.

6.예. ;-)

7.좋은 의미는 프로그래밍에서 중요합니다.

'PHP' 카테고리의 다른 글

티스토리툴바