REST 스타일 의 응용 프로그램 구현

촌 스 럽 다 고 웃 지 마 세 요. 왜냐하면 저 는 최근 에 야 REST 스타일 을 들 었 기 때 문 입 니 다. 예전 에는 / category / product / pid 라 고 생각 했 습 니 다.
이러한 주 소 는 매우 아름 답지 만 그것 은 이미지 일 뿐 입 니 다. 깊이 이해 한 후에 클 라 이언 트 의 Ajax Engine 과 Server 측의 서비스 조합 이 있어 야 REST 스타일 의 응용 을 실현 할 수 있 습 니 다. 다음은 제 실험 입 니 다.
문제
대외 적 으로 어떤 서 비 스 를 제공 해 야 합 니까?서버 측의 서 비 스 는 많은 브 라 우 저 요청 을 받 을 수도 있 고 제3자 응용 프로그램 에 의 해 호출 될 수도 있 기 때문에 전체적으로 이 대외 적 인 '응용 프로그램 인터페이스' (API) 를 고려 하여 인터페이스의 안정성 을 최대한 유지 해 야 한다.REST 는 하나의 스타일 이 고 자신의 규칙 을 형 성 했 기 때문에 이러한 응용 을 구축 하려 면 가능 한 한 REST 의 원칙 을 따라 야 한다.
 
한 축구 서비스의 경우 많은 관중 들 이 경기 의 기록 을 보고 새로운 경기 기록 을 올 리 며 경기 기록 을 갱신 하고 기 존의 경 기 를 수정 하거나 경 기 를 삭제 하 라 고 요구 할 것 이다.이렇게 설명 하면 우 리 는 다양한 서 비 스 를 제공 하고 최종 적 으로 일치 성 을 유지 하 는 일 에 쓰 러 질 것 이다.그럼 어떻게 해 야 할 까요? 고객 의 가능 한 요청 방식 을 고려 해 보 세 요.
GET 방식 으로 새 경기 서 비 스 를 요청 합 니 다:
http://example.com/newMatch?id=995&bluebaggers=150&redlegs=60
POST 또는 PUT 방식 으로 새 경기 서 비 스 를 요청 합 니 다.
http://example.com/newMatch
추가 XML 은:

    150
    60

CGI 스타일 의 POST 또는 PUT 요청:
http://example.com/newMatch
요청 체:
id=995&bluebaggers=150&redlegs=60
또는 유지보수 서비스의 GET 요청:
http://example.com/matchMaintenance/command=newMatch&id=995&bluebaggers=150&redlegs=60
POST 요청
http://example.com/matchMaintenance/command=newMatch
15060
이런 식 으로 유추 하면 이런 기능 이 많이 있 을 수 있다.어떤 사람들 은 이것 이 문제 가 아니 라 점점 더 많은 요구 에 대해 우 리 는 서 비 스 를 구축 한 후에 해당 하 는 설명 을 하면 된다 고 생각한다.하지만 그 는 단점 이 있다.
아마도 우 리 는 방문 이 스 크 립 트 에서 온 것 이 라 고 가정 할 것 이다. 그러면 이런 상황 은 좀 간단 할 것 이다.그러나 실제로 웹 브 라 우 저 (후퇴 와 리 셋 단추 의 문제 가 존재 할 수 있 음), 웹 서버 (캐 시 와 컴 파일 문제 가 있 을 수 있 음), 인터넷 경로 와 캐 시 문제, 파충류 의 소란 에 대응 하고 일부 개인 사이트 가 사이트 내용 을 캡 처 하 는 등 여러 가지 요소 가 관련 될 수 있다.우리 가 이런 서로 다른 요 구 를 고려한다 면, 우리 의 절 차 는 더욱 건장 하 게 표현 할 수 있 을 것 이다.
이상 적 인 상황 에서 하나의 서 비 스 는 자기 설명 능력 이 있어 야 한다.만약 에 하나의 서비스 가 약 속 된 조건 하에 서 세 워 진다 면 사람들 은 쉽게 적응 하고 후속 적 인 개발 을 할 수 있 을 것 이다.
REST 는 이러한 요 소 를 고려 하여 RESTful API 를 사용 하여 위의 서 비 스 를 실현 할 수 있다.
RESTful 원칙 소개
REST 의 주요 원칙 은 다음 과 같다.
URL 로 자원 을 표시 합 니 다.자원 은 상업 실체 와 같이 우리 가 API 실체 로 나타 나 고 싶 은 일부분 이다.보통 하나의 명사 로 모든 자원 은 하나의 유일한 URL 로 표시 된다.
HTTP 방법 은 조작 을 나타 낸다.REST 는 HTTP 의 방법, 특히 GET, POST, PUT 와 DELETE 를 충분히 이용 했다.XML HttpRequest 대상 이 모든 방법 을 실 현 했 음 을 주의 하 십시오. 구체 적 으로 W3C HTTP 1.1 Specification 을 참조 할 수 있 습 니 다.
즉, 클 라 이언 트 의 모든 요청 에는 URL 과 HTTP 방법 이 포함 되 어 있다.위의 예 로 돌아 가면 경 기 는 분명히 하나의 실체 이다. 그러면 특정한 경기 에 대한 요 구 는 다음 과 같다.

 http://example.com/matches/995

 
이런 방식 은 명확 하고 정확 한 명명 방식 과 다 를 수 있 지만 이런 형식 을 따 르 면 우 리 는 곧 GET, DELETE, UPDATE 와 새로운 작업 을 할 수 있다.
RESTful 의 원칙:
1. URL 표시 자원
2. HTTP 방법 은 조작 을 나타 낸다.
3. GET 는 조작 을 요청 하 는 데 사 용 될 뿐 GET 작업 은 서버 의 상 태 를 영원히 수정 해 서 는 안 됩 니 다.그러나 이것 도 구체 적 인 상황 을 분석 해 야 한다. 예 를 들 어 한 페이지 의 카운터 가 방문 할 때마다 서버 데이터 의 변 화 를 일 으 켰 지만 상업 적 으로 중요 한 변화 가 아니 기 때문에 GET 방식 으로 데 이 터 를 수정 할 수 있다.
GET 방식 으로 데이터 가 손 해 를 입 은 사례 를 수정 하 는 사례
Witness the the debacle caused by the Google Accelerator interacting with non-RESTful services in mid-2005. The accelerator jumps ahead of the user and prefetches each link in case they should click on it (a non-Ajaxian example of Predictive Fetch). The problem came when users logged into non-RESTful applications likeBackpack. Because Backpack deletes items using GET calls, the accelerator - in its eagerness to activate each GET query - ended up deleting personal data. This could happen with regular search engine crawlers too, though the issue doesn't tend to come up because they don't have access to personal accounts.
4. 서 비 스 는 무상 태 여야 한다
상태 있 는 세 션 에서 서버 는 이전의 정 보 를 기록 할 수 있 습 니 다.RESTful 스타일 에 서 는 서버 에 상 태 를 기록 하지 말 아야 합 니 다. 그래 야 서버 가 확장 성 을 가 질 수 있 습 니 다.물론 클 라 이언 트 에서 쿠키 를 사용 할 수 있 고 클 라 이언 트 가 서버 에 요청 을 보 낼 때 만 사용 할 수 있 습 니 다.
5. 서 비 스 는 '幂 등' 이 어야 한다
'幂 등' 은 서비스 에 메 시 지 를 보 낼 수 있다 는 뜻 으로 다시 한 번 힘 들 이지 않 고 같은 메 시 지 를 서비스 에 보 낼 수 있다.예 를 들 어 '995 번 째 경 기 를 삭제 합 니 다' 라 는 메 시 지 를 보 내 면 한 번 보 낼 수도 있 고 열 번 연속 보 낼 수도 있 으 며 마지막 결 과 는 일치 합 니 다.물론 RESTful 의 GET 요청 은 서버 상 태 를 거의 바 꾸 지 않 기 때문에 보통 멱 등 이다.메모: POST 요청 은 "멱 등" 으로 정의 할 수 없습니다. 특히 새 자원 을 만 들 때 한 번 에 자원 을 만 들 기 를 요청 하고 여러 번 요청 하면 여러 자원 을 만 듭 니 다.
6. 포옹 하이퍼링크
7. 서 비 스 는 자기 설명 을 해 야 한다.
예컨대 http://example.com/match/995 구체 적 인 경 기 를 요 청 했 지만 http://example.com/match 어떠한 실체 에 대해 서도 요청 하지 않 았 기 때문에 소개 정 보 를 되 돌려 야 한다.
8. 서비스 제약 데이터 형식.데이터 가 요구 에 부합 되 어야 하 는 형식
 
PHP 프로그램 에서 이러한 REST 스타일 의 URL 을 실현 하려 면 프로그램 만 으로 는 안 되 고 서버 에서 rewrite 규칙 을 설정 해 야 합 니 다. 예 를 들 어 REST 스타일 의 자원 요청:
http://www.api.com/product/113
스 크 립 트
http://www.api.com/product.php?id=113
이것 은 Query String 을 기반 으로 한 것 이 며, index. php 입 구 를 통일 적 으로 만 든 다음 URI 를 처리 하 는 방식 으로 이 루어 집 니 다. 예 를 들 어:
http://www.api.com/index.php/product/113
이러한 URL 은 rewrite 를 통 해 rest 스타일 을 실현 할 수 있 습 니 다.한 마디 로 하면 REST 는 프로그램 디자인 의 스타일 로 우리 에 게 자신의 응용 디자인 을 정리 하 는 데 원칙 을 제공 했다. 이런 원칙 이 가 져 온 역 사 를 이용 하 는 동시에 실제 상황 에 따라 유연 하 게 처리 할 수 있다.