REST API 란 무엇입니까? REST는 Representational State Transfer의 약어입니다. 가장 많이 사용되는 웹 서비스 기술에 대한 거의 의미 없는 설명입니다! REST API는 두 컴퓨터 시스템이 웹 브라우저 및 서버와 유사한 방식으로 HTTP를 통해 통신하는 방법입니다.
둘 이상의 시스템간에 데이터를 공유하는 것은 항상 소프트웨어 개발의 기본 요구 사항이었습니다.
예를 들어, 자동차 보험 구매를 고려하십시오. 보험사는 차량 등록 기관, 신용 기관, 은행 및 기타 시스템에 데이터를 요청할 수 있도록 귀하와 귀하의 차량에 대한 정보를 얻어야 합니다. 이 모든 것이 실시간으로 투명하게 발생하여 정책을 제공 할 수 있는지 여부를 결정합니다.
REST API 예
임의의 프로그래밍 농담을 요청하려면 브라우저에서 다음 링크를 엽니다.
https://official-joke-api.appspot.com/jokes/programming/random
이것은 RESTful 웹 서비스로 구현 된 공용 API입니다 (REST 규칙을 따릅니다). 브라우저에 다음과 같은 끔찍한 JSON 형식 프로그래밍 농담이 표시됩니다.
[
{
"id": 29,
"type": "programming",
"setup": "There are 10 types of people in this world...",
"punchline": "Those who understand binary and those who don't"
}
]동일한 URL을 요청하고 curl과 같은 HTTP 클라이언트를 사용하여 응답을 받을 수 있습니다.
curl "https://official-joke-api.appspot.com/jokes/programming/random"HTTP 클라이언트 라이브러리는 JavaScript의 Fetch 및 PHP의 file_get_contents()를 포함하여 널리 사용되는 모든 언어 및 런타임에서 사용할 수 있습니다. JSON 응답은 기계에서 읽을 수 있으므로 HTML 또는 기타 형식으로 구문 분석하고 출력 할 수 있습니다.
REST API 및 Rest
다양한 데이터 통신 표준이 수년에 걸쳐 발전해 왔습니다. 일반적으로 엄격한 메시징 규칙을 설정하는 CORBA, SOAP 또는 XML-RPC를 포함한 표준을 접했을 수 있습니다.
REST는 2000 년 Roy Fielding에 의해 정의되었으며 훨씬 더 간단합니다. 이는 표준이 아니라 RESTful 웹 서비스에 대한 권장 사항 및 제약 조건의 집합입니다. 여기에는 다음이 포함됩니다.
RESTful 웹 서비스 생성
RESTful 웹 서비스 요청에는 다음이 포함됩니다.
| HTTP method | CRUD | Action |
|---|---|---|
| GET | read | returns requested data |
| POST | create | creates a new record |
| PUT or PATCH | update | updates an existing record |
| DELETE | delete | deletes an existing record |
예 :
3. HTTP 헤더. 인증 토큰 또는 쿠키와 같은 정보는 HTTP 요청 헤더에 포함될 수 있습니다.
4. Body Data. 데이터는 일반적으로 HTML <form> 제출과 동일한 방식으로 또는 단일 JSON 인코딩 데이터 문자열을 전송하여 HTTP 본문에서 전송됩니다.
REST API 응답
응답 페이로드는 데이터, HTML, 이미지, 오디오 파일 등 실용적인 것이 될 수 있습니다. 데이터 응답은 일반적으로 JSON으로 인코딩되지만 XML, CSV, 단순 문자열 또는 기타 형식을 사용할 수 있습니다. 반환 형식이 요청에 지정되도록 허용 할 수 있습니다 (예 : / user / 123? format = json 또는 / user / 123? format = xml).
응답 헤더에 적절한 HTTP 상태 코드도 설정해야 합니다. 200 OK는 성공적인 요청에 가장 많이 사용되지만 레코드가 생성 될 때 201 Created가 반환 될 수도 있습니다. 오류는 400 Bad Request, 404 Not Found, 401 Unauthorized 등과 같은 적절한 코드를 반환해야 합니다.
Cache-Control 또는 Expires 지시문을 포함하여 다른 HTTP 헤더를 설정하여 응답이 오래된 것으로 간주되기 전에 캐시 될 수 있는 시간을 지정할 수 있습니다.
그러나 엄격한 규칙은 없습니다. 끝점 URL, HTTP 메서드, 본문 데이터 및 응답 유형을 원하는 대로 구현할 수 있습니다. 예를 들어 POST, PUT 및 PATCH는 종종 같은 의미로 사용되므로 모든 사용자가 레코드를 생성하거나 업데이트합니다.
REST API“Hello World”예제
다음 코드는 Node.js Express 프레임 워크를 사용하여 RESTful 웹 서비스를 만듭니다. 단일 /hello/엔드 포인트가 GET 요청에 응답합니다.
Node.js가 설치되어 있는지 확인한 다음 restapi라는 새 폴더를 만듭니다. 다음 내용으로 해당 폴더 내에 새 package.json 파일을 만듭니다.
{
"name": "restapi",
"version": "1.0.0",
"description": "REST test",
"scripts": {
"start": "node ./index.js"
},
"dependencies": {
"express": "4.17.1"
}
}명령 줄에서 npm install을 실행하여 종속성을 가져온 후 다음 코드로 index.js 파일을 만듭니다.
// simple Express.js RESTful API
'use strict';
// initialize
const
port = 8888,
express = require('express'),
app = express();
// /hello/ GET request
app.get('/hello/:name?', (req, res) =>
res.json(
{ message: `Hello ${req.params.name || 'world'}!` }
)
);
// start server
app.listen(port, () =>
console.log(`Server started on port ${port}`);
);npm start를 사용하여 명령 줄에서 응용 프로그램을 시작하고 브라우저에서 http://localhost:8888 /hello/를 엽니다. GET 요청에 대한 응답으로 다음 JSON이 표시됩니다.
{
"message": "Hello world!"
}API는 또한 사용자 지정 이름을 허용하므로 http://localhost:8888/hello/everyone/은 다음을 반환합니다.
{
"message": "Hello everyone!"
}클라이언트 측 REST API 요청 및 CORS
URL http : // localhost : 8888 /의 브라우저에서 실행 된 다음 HTML 페이지를 고려하십시오.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>REST test</title>
</head>
<body>
<script>
fetch('http://localhost:8888/hello/')
.then((response) => {
return response.json();
})
.then((json) => {
console.log(json);
});
</script>
</body>
</html>가져 오기 호출은 동일한 API 요청을 만들고 브라우저 콘솔에 Object {message : "Hello world!"가 표시됩니다. } 예상대로.
그러나 이제 RESTful 웹 서비스가 http://mydomain.com/hello/ 도메인의 웹에 게시되었다고 가정합니다.
페이지 JavaScript fetch () URL이 그에 따라 변경되지만 브라우저에서 http : // localhost : 8888 /을 열면 이제 콘솔 오류 Cross-Origin Request Blocked가 반환됩니다.
보안을 위해 브라우저는 페이지가 호스팅 되는 동일한 도메인에 대한 클라이언트 측 XMLHttpRequest 및 Fetch API 호출 만 허용합니다.
다행히 CORS (Cross-Origin Resource Sharing)를 사용하면 보안 제한을 우회 할 수 있습니다. Access-Control-Allow-Origin HTTP 응답 헤더를 설정하면 브라우저가 요청을 허용 함을 알 수 있습니다. 특정 도메인으로 설정하거나 모든 도메인에 대해 * (위의 Joke API에서 수행)로 설정할 수 있습니다.
따라서 웹 서비스 API 코드는 모든 도메인에서 실행되는 클라이언트 측 스크립트에서 액세스 할 수 있도록 변경 될 수 있습니다.
// /hello/ GET request
app.get('/hello/:name?', (req, res) =>
res
.append('Access-Control-Allow-Origin', '*')
.json(
{ message: `Hello ${req.params.name || 'world'}!` }
)
);또는 Express.js 미들웨어 함수가 모든 엔드 포인트 요청에 헤더를 추가 할 수 있습니다.
// enable CORS
app.use((req, res, next) => {
res.append('Access-Control-Allow-Origin', '*');
next();
});
// /hello/ GET request
// ...REST API 과제
REST의 성공은 단순성 때문입니다. 개발자는 원하는 대로 RESTful API를 자유롭게 구현할 수 있지만 이로 인해 더 많은 문제가 발생할 수 있습니다.
REST 끝점 합의
다음 끝점을 고려하십시오.
모두 사용자 123에 대한 데이터를 가져 오는 데 유효한 옵션입니다. 작업이 더 복잡하면 조합 수가 더 늘어납니다.
예를 들어, 성이 'A'로 시작하고 생년월일 순으로 정렬 된 경우 레코드 51부터 companyX에서 근무하는 10 명의 사용자를 반환합니다.
궁극적으로 URL 형식은 중요하지 않지만 API 간의 일관성이 중요합니다. 많은 개발자가 있는 대규모 코드베이스에서는 달성하기 어려울 수 있습니다.
REST API 버전 관리
API 변경은 불가피하지만 엔드 포인트 URL은 내부 및 / 또는 타사 애플리케이션에서 사용될 때 무효화되어서는 안됩니다.
API는 종종 호환성 문제를 피하기 위해 버전이 지정됩니다 (예 : /2.0/user/123이 /user/123을 대체 함). 그러나 이전 엔드 포인트는 활성 상태로 유지됩니다. 그러나 여러 API가 유지되므로 작업 부하가 증가합니다. 오래된 API는 결국 폐기 될 수 있지만 프로세스에는 신중한 계획이 필요합니다.
REST API 인증
위에 표시된 Joke API는 열려 있습니다. 모든 시스템은 승인없이 농담을 가져올 수 있습니다. 이것은 개인 데이터에 액세스하거나 업데이트 및 삭제 요청을 허용하는 API에서는 실행되지 않습니다.
RESTful API와 동일한 도메인에 있는 클라이언트 측 애플리케이션은 다른 HTTP 요청과 마찬가지로 쿠키를 보내고 받습니다. (이전 브라우저에서 Fetch ()를 사용하려면 자격 증명 init 옵션을 설정해야 합니다.) 따라서 사용자가 로그인 되어 있고 적절한 권한이 있는지 확인하기 위해 API 요청을 확인할 수 있습니다.
타사 응용 프로그램은 다른 인증 방법을 사용해야 합니다. 일반적인 인증 옵션은 다음과 같습니다.
API 인증은 사용 컨텍스트에 따라 다릅니다. 경우에 따라 타사 애플리케이션은 특정 권한 및 권한을 가진 다른 로그인 사용자로 간주됩니다 (예 :지도 API에서 길 찾기 생성). 다른 경우에는 등록 된 사용자가 타사 애플리케이션을 사용하고 있으며 이메일 콘텐츠 또는 문서를 가져올 때와 같이 해당 데이터에만 액세스 할 수 있습니다.
REST API 보안
RESTful API는 애플리케이션에 액세스하고 조작 할 수 있는 또 다른 경로를 제공합니다. 흥미로운 해킹 대상이 아니더라도 잘못 작동하는 클라이언트는 매초 수천 개의 요청을 보내고 서버를 중단 시킬 수 있습니다.
보안은 이 문서의 범위를 벗어나지 만 일반적인 모범 사례는 다음과 같습니다.
여러 요청 및 불필요한 데이터
RESTful API는 구현에 따라 제한됩니다. 응답에는 필요한 것보다 더 많은 데이터가 포함되거나 모든 데이터에 액세스하기 위해 추가 요청이 필요할 수 있습니다.
저자 및 도서 데이터에 대한 액세스를 제공하는 RESTful API를 고려하십시오. 상위 10 개 판매 도서에 대한 데이터를 표시하기 위해 고객은 다음을 수행합니다.
이것은 N + 1 문제로 알려져 있습니다. 상위 요청의 각 결과에 대해 N 개의 API 요청이 작성되어야 합니다.
이것이 일반적인 사용 사례 인 경우 반환 된 모든 책에 이름, 나이, 국가, 전기 등과 같은 전체 저자 세부 정보가 포함되도록 RESTful API를 변경할 수 있습니다. 또한 다른 책에 대한 자세한 내용을 제공 할 수 있습니다.이 경우 응답 페이로드가 상당히 증가합니다!
대량 응답을 방지하기 위해 API를 조정하여 작성자 세부 정보를 제어 할 수 있습니다 (예 :? author_details = basic).하지만 옵션의 수는 금방 혼란스러워 질 수 있습니다.
GraphQL은 REST API를 수정합니까?
이러한 REST 수수께끼로 인해 Facebook은 웹 서비스 쿼리 언어인 GraphQL을 만들었습니다. 웹 서비스를 위한 SQL이라고 생각하십시오. 단일 요청은 필요한 데이터와 반환 방법을 정의합니다.
GraphQL은 RESTful API가 제기하는 많은 문제를 해결합니다. 즉, Facebook과 비슷한 문제가 있는 회사는 거의 없습니다. RESTful API가 단순한 시작점 이상으로 발전하면 GraphQL을 고려해 볼 가치가 있습니다.
REST API 링크 및 개발 도구
REST API 디자인을 더럽히려면 Node.js를 사용한 RESTful 웹 API 디자인을 권장합니다. 이미 알고 있는 JavaScript로 기능 API 빌드를 시작하십시오.
모든 언어로 RESTful API 개발을 지원하는 수많은 도구가 있습니다. 주목할 만한 옵션은 다음과 같습니다.
농담, 통화 변환, 지오 코딩, 정부 데이터 및 생각할 수 있는 모든 주제를 처리하는 많은 공용 REST API가 있습니다.
대부분은 무료이지만 일부는 API 키를 등록하거나 다른 인증 방법을 사용해야 합니다. 분류 된 목록은 다음과 같습니다.
자체 웹 서비스를 구현하기 전에 자체 프로젝트에서 몇 가지 RESTful API를 사용해보십시오.
등록된 댓글이 없습니다.
