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

그래서 REST API 작성에 대한 기사를 살펴 보았습니다. 그리고 그들 중 일부는 모든 유형의 HTTP 요청을 사용하도록 제안합니다 PUT DELETE POST GET. 예를 들어 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;
}

물론, 웹 서비스에 대해 잘 모르고 있습니다 (아직). 그러나 일반 또는 메소드 이름과 모든 매개 변수를 포함하는 JSON 객체를 수락 한 다음 JSON으로 응답 하는 것이 쉽지 않을 것 입니다. 우리는 쉽게 직렬화 / 역 직렬화 PHP의를 통해 수 및 다른 HTTP 요청 방법으로 처리 할 필요없이 우리가 그 데이터를 원하는대로 할.POSTGETjson_encode()json_decode()

뭔가 빠졌습니까?

업데이트 1 :

Ok-다양한 API를 파고 XML-RPC , JSON-RPC , SOAP , REST 에 대해 많이 배운 후이 유형의 API가 적합하다는 결론에 도달했습니다. 실제로 스택 교환은 사이트에서이 접근 방식을 거의 사용하고 있으며 이러한 사람들은 Stack Exchange API를 수행하는 작업을 알고 있다고 생각합니다 .

답변

의 아이디어 RE 표상 S 탓에 T 를 ransfer하지 않음을 가능한 한 가장 간단한 방법으로 데이터를 액세스하는 방법에 대한.

게시 요청을 사용하여 JSON에 액세스 할 것을 제안했는데 이는 데이터에 액세스 / 조작하는 데 가장 효과적인 방법입니다.

REST는 의미있는 데이터 액세스를 위한 방법입니다 . REST에서 요청이 표시되면 데이터에서 발생하는 상황에 즉시 대응해야합니다.

예를 들면 다음과 같습니다.

GET: /cars/make/chevrolet

시보레 자동차 목록을 반환 할 가능성이 높습니다. ~~좋은 REST API는 쿼리 문자열에 일부 출력 옵션을 통합 ?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에 새로운 시보레 말리부를 만들 것입니다. 내가 말할 가능성이 나머지 API를 직접 데이터베이스 구조와 관련 될 필요가 없기 때문에. 실제 데이터가 보호되도록 마스킹 인터페이스 일뿐입니다 (데이터베이스 구조에 대한 접근 자 및 변경자와 같은 것으로 생각하십시오).

이제 우리는 dem 등분 문제로 넘어 가야 합니다. 일반적으로 REST는 CRUD over HTTP를 구현 합니다. HTTP를 사용 GET, PUT, POST및 DELETE요청합니다.

매우 간단한 REST 구현은 다음 CRUD 맵핑을 사용할 수 있습니다.

Create -> Post
Read   -> Get
Update -> Put
Delete -> Delete

이 구현에는 문제가 있습니다. Post는 비등 전성 메서드로 정의됩니다. 이는 동일한 Post 메소드의 후속 호출은 다른 서버 상태를 초래 함을 의미합니다 . Get, Put 및 Delete는 dem 등원입니다. 즉, 여러 번 호출하면 동일한 서버 상태가됩니다.

이는 다음과 같은 요청을 의미합니다.

Delete: /cars/oldest

실제로 다음과 같이 구현할 수 있습니다.

Post: /cars/oldest?action=delete

이므로

Delete: /cars/id/123456

한 번 호출하거나 1000 번 호출하면 동일한 서버 상태가됩니다.

oldest품목 제거를 처리하는 더 좋은 방법 은 다음을 요청하는 것입니다.

Get: /cars/oldest

그리고 ID결과 데이터를 사용하여 delete요청하십시오.

Delete: /cars/id/[oldest id]

이 방법의 문제 는 요청 시점과 발행 시점 /cars사이에 다른 항목이 추가 된 경우입니다./oldestdelete

답변

이것은 보안 및 유지 관리 성 질문입니다.

안전한 방법

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

dem 등식 방법

가능하면 GET, HEAD, PUT 및 DELETE와 같은 ‘등전위 (idempotent)’방법을 사용해야합니다.이 방법은 부작용이 없으므로 제어하기 쉬운 오류가 적습니다.

출처

답변

요컨대 REST는 동사보다 명사를 강조합니다. API가 복잡 해짐에 따라 더 많은 명령이 아닌 더 많은 것을 추가합니다.

답변

당신은 물었다 :

정상적인 $ _POST를 통해 JSON 객체를 수락 한 다음 JSON에서도 응답하는 것이 쉽지 않을 것입니다

REST Wikipedia에서 :

RESTful 애플리케이션은 선택한 네트워크 프로토콜에서 제공하는 기존의 잘 정의 된 인터페이스 및 기타 내장 기능의 사용을 최대화하고 그 위에 새로운 애플리케이션 별 기능의 추가를 최소화합니다

내가 본 (작은) 것으로부터, 나는 이것이 일반적으로 기존 HTTP 동사의 사용을 최대화하고 가능한 강력하고 자명 한 서비스를 위해 URL 스킴을 설계함으로써 달성된다고 생각합니다.

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

반면에 SOAP RPC over HTTP는 각 응용 프로그램 디자이너가 명사와 동사 (예 : getUsers (), savePurchaseOrder (…))의 새롭고 임의적 인 어휘를 정의하도록 권장합니다. 일반적으로 HTTP ‘POST’동사에 중첩됩니다. 이는 인증, 캐싱 및 컨텐츠 유형 협상과 같은 많은 HTTP의 기존 기능을 무시하고 애플리케이션 설계자가 새로운 기능 내에서 이러한 기능 중 많은 기능을 다시 발명하게 할 수 있습니다.

작업중인 실제 객체는 모든 형식 일 수 있습니다. 아이디어는 사용자가 해당 리소스에서 수행하려는 작업 (쿼리, 상태 관리 / 돌연변이, 삭제)을 노출하기 위해 가능한 한 많은 HTTP를 재사용하는 것입니다.

당신은 물었다 :

뭔가 빠졌습니까?

REST 및 URI 구문 / HTTP 동사 자체에 대해 더 많은 정보가 있습니다. 예를 들어, 동사 중 일부는 dem 등원이고 다른 동사는 그렇지 않습니다. 나는 당신의 질문에서 이것에 대해 아무것도 보지 못했기 때문에 그것에 들어 가려고 노력하지 않았습니다. 다른 답변과 Wikipedia에는 좋은 정보가 많이 있습니다.

또한 진정으로 편안한 API를 사용하는 경우 활용할 수있는 HTTP를 기반으로 구축 된 다양한 네트워크 기술에 대해 배울 것이 많습니다. 인증부터 시작하겠습니다.

답변

확장을 사용하여 데이터 유형을 정의하는 것과 관련하여. 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

답변

뭔가 빠졌습니까?

예. 😉

이 현상은 균일 한 인터페이스 제약 때문에 존재합니다 . REST는 휠을 재창조하는 대신 기존 표준을 사용하는 것을 좋아합니다. HTTP 표준은 이미 확장 성이 뛰어난 것으로 입증되었습니다 (웹은 한동안 작동합니다). 왜 깨지지 않은 것을 고쳐야합니까?!

참고 : 클라이언트를 서비스에서 분리하려면 균일 한 인터페이스 제약 조건이 중요합니다. 클래스를 서로 분리하기 위해 클래스에 대한 인터페이스를 정의하는 것과 유사합니다. Ofc. 여기에 균일 한 인터페이스는 같은 표준으로 구성 HTTP , MIME 타입 , URI , RDF , 링크 된 데이터 Vocabs에 , 히드라의 Vocab의 등 …

답변

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

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

왜?

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

나는 보통 RESTFUL 웹 서비스를 구성하여 메소드와 같은 이름의 함수 콜백을 갖습니다.

나는 PHP를 사용하므로 function_exists를 사용한다. 함수가 존재하지 않으면 405 (METHOD NOT ALLOWED)를 던집니다.