REST API 이해 - 참을성이 없는 사람들을 위한 가이드

여기에 내 기사 크로스포스트

REST(Re프리젠테이션 State Transfer) API는 최신 웹 개발의 중추입니다. 이 기사에서는 최신 REST API를 생성하고 사용하는 방법, API를 만들 때 고려해야 할 설계 결정, REST의 기초가 되는 이론을 자세히 설명합니다.

실용 가이드

이 섹션에서는 엔드포인트, 메소드, 요청 및 응답을 다루는 HTTP와 함께 REST API를 사용하는 방법을 자세히 설명합니다. API 호출을 시작하고 프로젝트에 REST를 적용하는 데 필요한 모든 것을 찾을 수 있습니다.

URI를 구성하는 방법

일반적으로 URI를 처리할 수 있는 두 가지 주요 방법이 있습니다.

1. 액션으로
2. 자원

다음 두 URI를 고려하세요.

1. https://example.com/getUserData?id=1 (액션)
2. https://example.com/users/1(자원)

두 예시 모두 ID가 1인 사용자의 사용자 데이터를 검색하는 모습을 보여줍니다. 차이점은 첫 번째 예시에서는 /getUserData 경로가 작업을 수행하는 반면, 두 번째 예시에서는 /users/1 경로가 다음의 위치라는 점입니다. 자산인 경우 어떤 작업이 수행되고 있는지 나타내지 않습니다. 이러한 유형의 URI는 명사 역할을 한다고 말할 수 있습니다(동작, 즉 동사가 아닌 사물이기 때문입니다).

REST 패턴에서는 두 번째 예와 같이 URI를 엄격하게 사용하도록 지시합니다. 우리는 HTTP 메소드를 동사로 사용하여 해당 명사에 대한 작업을 수행할 수 있도록 URI를 명사가 되기를 원합니다. 예를 들어 HTTP 메소드 GET을 사용하여 /users/1에 대한 정보를 검색할 수 있지만 PUT을 사용하여 해당 사용자 정보를 업데이트하거나 DELETE를 사용하여 사용자를 완전히 삭제할 수 있습니다.

URI에 대해 마지막으로 주의할 점은 위의 예와 같이 개별 리소스(예: 이 경우 단일 사용자)를 참조할 때 URI는 해당 리소스에 대한 고유 식별자로 끝나야 한다는 것입니다. 특정 카테고리의 모든 리소스를 참조할 때는 고유 식별자를 생략해야 합니다.

1. https://example.com/users/1 - ID가 1인 특정 사용자를 참조합니다.
2. https://example.com/users - ID에 관계없이 모든 사용자를 참조합니다.

지원해야 할 조치

REST에서 지원하는 4가지 주요 작업은 CRUD라는 약어를 사용하여 기억합니다. Create, Read, U pdate, Dlete. 이러한 각 작업은 해당 작업을 수행하는 데 사용할 수 있는 HTTP 메서드에 매핑됩니다. 매핑은 다음과 같습니다.

Action	HTTP Method
Create	POST
Read	GET
Update	PUT / PATCH
Delete	DELETE

지원할 모든 작업 URI 조합

모든 REST API는 실제로 (최소) 5~6개의 경로입니다. 이 예에서 기본 엔드포인트는 /users이며 https://example.com에서 호스팅하는 척하겠습니다.

• https://example.com/users 받기
  • 조치: 모든 사용자 자산을 반환합니다(각 자산은 한 명의 사용자입니다)
  • 요청 본문: 비어 있음
  • 응답 본문: 사용자 자산 목록(JSON 배열)
• GET https://example.com/users/[id] ([id]는 변수입니다)
  • Action: 요청된 단일 사용자 자산만 반환
  • 요청 본문: 비어 있음
  • 응답 본문: 일치하는 ID가 있는 사용자 자산(JSON)
• 게시 https://example.com/users
  • 작업: 컬렉션에 하나의 사용자 자산을 추가합니다
  • 요청 본문: 새로운 사용자 자산을 생성하는 데 필요한 모든 데이터(특정 형식 필요 없음, JSON 권장)
  • 응답 본문: 고유 ID(JSON)가 삽입된 새로 생성된 자산
• PUT https://example.com/users/[id] ([id]는 변수입니다)
  • 액션: 기존 사용자 한 명의 데이터만 주어진 데이터로 완전히 대체합니다
  • 요청 본문: 변경 여부에 관계없이 기존 사용자의 데이터를 대체하는 데 필요한 모든 데이터(ID 빼기 - 특정 형식 필요 없음, JSON 권장)
  • 응답 본문: 일치하는 ID(JSON)와 함께 새로 업데이트된 자산
• (선택) PATCH https://example.com/users/[id] ([id]는 변수입니다)
  • 액션: 기존 사용자 한 명의 데이터만 부분적으로 해당 데이터로 대체합니다
  • 요청 본문: 업데이트가 필요한 데이터만(id 제외 - 특정 형식 필요 없음, JSON 권장)
  • 응답 본문: 일치하는 ID(JSON)와 함께 새로 업데이트된 자산
• DELETE https://example.com/users/[id] ([id]는 변수입니다)
  • 작업: 사용자 테이블에서 레코드 하나만 삭제합니다
  • 요청 본문: 없음
  • 응답 본문: 없음(HTTP 응답 코드만) OR 일치하는 ID와 함께 방금 삭제된 자산의 데이터(JSON)

디자인 고려 사항

REST 패턴 사용 여부로 엔드포인트를 정의하는 것 외에도 엔드포인트 구축을 시작하기 전에 고려해야 할 사항이 많이 있습니다. 나중에 엔드포인트를 업데이트할 가능성이 있습니까? 출력물이 사용자에게 유용한 힌트를 제공해야 합니까? REST가 귀하의 상황에 적합한 패턴인가요? 다음 질문에 답해 보겠습니다.

엔드포인트 버전 관리

나중에 더 쉽게 변경할 수 있도록 처음부터 API 버전 관리를 고려하는 것이 좋습니다. 사용자가 사용하기로 선택한 API 버전을 확인하는 방법에는 몇 가지가 있습니다.

• URI 버전 관리
  • 버전 번호는 일반적으로 기본 위치에 있는 URL 경로에 통합됩니다.
  • 예:
  • https://example.com/v1/users/1
  • https://example.com/v2/users/1
• 쿼리 매개변수
  • 버전 번호는 API 엔드포인트에 쿼리 매개변수로 추가됩니다
  • 예:
  • https://example.com/users/1?apiVersion=1
  • https://example.com/users/1?apiVersion=2
• 헤더 기반
  • 버전 번호는 구체적이고 고유한 헤더 필드입니다
  • 예(요청 헤더):
  • x-api-버전: 1
  • x-api-버전: 2
• 콘텐츠 협상
  • 버전은 표현 상태나 미디어 유형에 따라 결정됩니다.
  • 아래 예에서 서버 코드는 firstName이 첫 번째 버전에 대한 것이며 다음 버전에서는 주어진 이름으로 변경되었음을 알 수 있습니다.
  • 예(요청 본문):
  • { 이름: '헨리' }
  • { 주어진 이름: '헨리' }

빠른 REST API 모의

가끔 가지고 놀아보는 것이 작동 방식을 배울 수 있는 최고의 도구입니다. REST를 시연하기 위해 제가 가장 좋아하는 라이브러리 중 하나는 json-server입니다. 설정은 매우 간단합니다. 몇 단계만 거치면 됩니다.

JSON 서버 설치

npm install json-server

간단한 데이터 저장소 만들기

{
  "users": [
    { "id": "1", "username": "gorwell", "email": "gorwell@gmail.com" },
    { "id": "2", "username": "cdickens", "email": "cdickens@gmail.com" },
    { "id": "3", "username": "jausten", "email": "jausten@gmail.com" },
    { "id": "4", "username": "vwoolf", "email": "vwoolf@gmail.com" },
    { "id": "5", "username": "sking", "email": "sking@gmail.com" }
  ]
}

서버 시작

npx json-server db.json

로컬 서버에 대해 HTTP 요청하기

curl -X GET http://localhost:3000/users/1

쉬운 CRUD 데이터 그리드

완전히 작동하는 REST 엔드포인트는 ZingGrid를 사용하여 데이터 그리드에 쉽게 연결할 수 있습니다. 기본 REST URI를 아래와 같은 요소의 src 속성

<zing-grid src="http://localhost:3000/users" editor-controls></zing-grid>

최종 생각

REST API는 웹 전반에 걸쳐 다양한 모양과 크기로 제공되며 각 API는 특정 요구 사항에 맞게 조정됩니다. 신중하게 URI를 구성하고, 올바른 작업을 선택하고, 버전 관리를 염두에 두면 개발자가 즐겁게 작업할 수 있는 간단하고 유연한 API를 만들 수 있습니다. 이러한 기본 단계를 통해 빠른 프로토타입이라도 시간이 지나도 견고하고 신뢰할 수 있는 API로 발전할 수 있습니다.

위 내용은 REST API 이해 - 참을성이 없는 사람들을 위한 가이드의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!