
REST는 표현 상태 전송의 약어입니다 . RESTFUL API는 HTTP 요청을 사용하여 데이터에 액세스하고 변경하는 애플리케이션 프로그램 인터페이스 (API) 의 아키텍처 스타일입니다. 해당 데이터는 데이터 유형을 얻고, 게시, 게시 및 삭제하는 데 사용될 수 있으며, 이는 리소스에 관한 작업의 읽기, 업데이트, 작성 및 삭제를 나타냅니다. 자세한 내용은
모든 REST 기반 아키텍처에 사용되는 주요 기능은 다음과 같습니다.
응용 프로그램은 특정 제약이나 원칙을 충족해야합니다. 이 원칙에 대한 자세한 내용을 보자.
6 가지 지상 원칙이 있습니다. 아래에는 6 가지 안내 원칙이 있습니다.
SANTESS : 클라이언트에서 서버로 전송 된 요청에는이를 완전히 이해하는 데 필요한 모든 필요한 정보가 포함되어 있습니다. URI, 쿼리 스트링 매개 변수, 본문 또는 헤더의 일부일 수 있습니다. URI는 자원을 고유하게 식별하는 데 사용되며 신체는 요청 자원의 상태를 보유합니다. 서버에서 처리가 수행되면 적절한 응답이 헤더, 상태 또는 응답 본문을 통해 클라이언트에게 다시 전송됩니다.
클라이언트-서버 : 서버와 클라이언트를 분리하는 균일 한 인터페이스가 있습니다. 문제를 분리하면 여러 플랫폼에서 사용자 인터페이스의 휴대 성을 향상시키고 서버 구성 요소의 확장 성을 향상시키는 데 도움이됩니다.
균일 한 인터페이스 : 응용 프로그램 전체에서 균일 성을 얻기 위해 REST는 다음과 같은 4 가지 인터페이스 제약 조건을 정의했습니다.
Resource identification
Resource Manipulation using representations
Self-descriptive messages
Hypermedia as the engine of application state
캐시 가능 : 더 나은 성능을 제공하기 위해 응용 프로그램은 종종 캐시 가능합니다. 서버의 응답을 캐시 가능 또는 캐시 불가능한 것으로 표시하여 수행됩니다. 응답이 캐시 가능로 정의되면 클라이언트 캐시는 향후 동등한 응답에 대해 응답 데이터를 재사용 할 수 있습니다. 또한 오래된 데이터의 재사용을 방지하는 데 도움이됩니다.
계층화 된 시스템 : 계층화 된 시스템 아키텍처를 사용하면 구성 요소 동작을 제한하여 응용 프로그램이 더 안정적 일 수 있습니다. 이 아키텍처는로드 밸런싱을 가능하게하며 확장 성을 촉진하기위한 공유 캐시를 제공합니다. 계층 아키텍처는 또한 각 층의 구성 요소가 다음 즉시 계층을 넘어 상호 작용할 수 없으므로 응용 프로그램의 보안을 향상시키는 데 도움이됩니다.
주문형 코드 : 주문형 코드는 선택적 제약 조건이며 가장 적게 사용됩니다. 클라이언트 코드 또는 애플릿이 인터페이스를 통해 응용 프로그램 내에서 사용할 수 있도록 다운로드 및 확장 할 수 있습니다. 본질적으로 자체 코드 구조에 의존하지 않는 스마트 애플리케이션을 만들어 클라이언트를 단순화합니다.
이제 효율적인 응용 프로그램을 제공하기 위해 REST API가 무엇인지, 무엇을 생각 해야하는지 알았으므로 더 깊이 빠져 나와 모든 트렌드 기술과 프레임 워크를 사용하여 REST API를 구축하는 프로세스를 보자.
REST 및 간단한 객체 액세스 프로토콜 (SOAP)은 웹 서비스를 호출하기위한 다양한 방법을 제공합니다. REST는 건축 스타일이며 SOAP는 XML 기반 메시지 교환에 대한 표준 통신 프로토콜 사양을 정의합니다. 휴식 응용 프로그램은 비누를 사용할 수 있습니다.
편안한 웹 서비스는 무국적입니다. REST 기반 구현은 SOAP에 비해 간단하지만 사용자는 나머지 웹 서비스 인터페이스를 설명하는 표준 규칙 세트가 없으므로 컨텍스트와 컨텐츠를 통과하는 것을 이해해야합니다. REST 서비스는 모바일과 같은 제한된 프로필 장치에 유용하며 기존 웹 사이트와 쉽게 통합 할 수 있습니다.
SOAP는 휴게소 디자인보다 메인 코드 모듈을 함께 연결하는 저수준의 인프라 코드를 의미하는 배관 코드가 적습니다. 웹 서비스 설명 언어는 서비스의 메시지, 바인딩, 운영 및 위치를 정의하기위한 공통 규칙 세트를 설명합니다. SOAP 웹 서비스는 비동기 처리 및 호출에 유용합니다.
REST API를 개발할 때 고려해야 할 몇 가지 사항이 있습니다.
응답 데이터의 매우 큰 페이로드는 요청 완료, 기타 서비스 호출 및 성능 저하에 영향을 미칩니다. 아시다시피, 이제 우리는 현재 주문과는 달리 고객에 대한 모든 주문을 반환하고 있기 때문에 일부 성과 비판을 처리해야합니다.
GZip Compression 사용하여 페이로드 크기를 줄일 수 있습니다. 이는 웹 앱 (클라이언트 측)에서 응답의 다운로드 크기를 줄이고 업로드 속도를 높이거나 일부 엔티티 (주문)의 생성을 증가시킵니다. 웹 API에서 Deflate compression 사용할 수 있습니다. 또는 accept-encodingRequest 헤더를 GZIP로 업데이트 할 수 있습니다 .
캐싱은 API의 성능을 향상시키는 가장 쉬운 방법 중 하나입니다. 동일한 응답을 자주 제공하는 요청이있는 경우 해당 응답의 캐시 버전은 추가 서비스 호출/데이터베이스 쿼리를 피하는 데 도움이됩니다. 캐싱을 사용할 때 캐시의 데이터를 주기적으로 무효화 할 때, 특히 새 데이터 업데이트가 발생할 때 확인하려고합니다.
고객이 자동차 부품 주문을 원하고 앱이 일부 자동 부품 API를 요청하여 부품 가격을 가져 오기를 원한다고 가정 해 봅시다. 응답 (부분 가격)은 매주 한 번만 변경되므로 (@ 1:00 AM), 우리는 그때까지 나머지 시간 동안 응답을 캐시 할 수 있습니다. 이로 인해 우리는 매번 새로운 전화를 걸어 같은 부품 가격을 반환하지 못하게됩니다. 유사한 경우 캐시를 사용하여 추가 호출이나 요청을 피할 수 있습니다.
느린 네트워크는 가장 강력하게 설계된 API의 성능을 저하시킵니다. 신뢰할 수없는 네트워크는 가동 중지 시간을 유발하여 조직이 SLA, 서비스 약관을 위반하고 고객에게 한 약속을 위반할 수 있습니다. 원하는 수준의 성능을 유지할 수 있도록 적절한 네트워크 인프라에 투자하는 것이 중요합니다. 이는 충분한 클라우드 리소스 및 인프라를 활용하고 구매하여 달성 할 수 있습니다 (example: in AWS, allocate the proper # of EC2 instances, use a Network Load Balancer) . 또한 많은 배경 프로세스가있는 경우 요청을 차단하지 않도록 별도의 스레드에서 실행하십시오. 또한 Cloudfront와 같은 거울 및 CDN (Content Delivery Networks)을 사용하여 지구의 여러 부분 주변에서 더 빠른 요청을 제공 할 수 있습니다.
API가 악의적이고 의도적이거나 엔지니어가 API를 호출하여 일부 로컬 애플리케이션에서 루프에서 실행할 때 API가 DDOS 공격을 겪을 수있는 상황을 가질 수 있습니다. 트랜잭션을 측정하고 monitoring the number of how many transactions occur per IP Address, or per SSO/JWT Token (if the customer/calling app is authorized before calling the API) .
이 방법에 대한이 방법은 API를 늦추고 우발적 인 전화/실행을 처리하는 데 도움이되는 과도한 요청을 줄이며 가능한 악의적 인 활동을 적극적으로 모니터링하고 식별하는 데 도움이됩니다.
엔지니어들 사이의 일반적인 오해와 패치 운영이 동일한 결과를 산출하는 것이 동일한 결과를 얻을 수 있습니다. 그들은 리소스 업데이트에서 비슷하지만 각각 업데이트를 다르게 수행합니다. 전체 리소스에 업데이트를 전송하여 작업 업데이트 리소스를 넣습니다. 패치 작업은 업데이트가 필요한 리소스에만 부분 업데이트를 적용합니다. 더 작은 페이로드를 생성하고 규모에 따라 성능을 향상시키는 Inpatch 호출.
Pro-Tip: Even though PATCH calls can limit the request size, you should note that it is not Idempotent.
Meaning, it is possible that a PATCHcan yield different results with a series of multiple calls.
So, you should carefully and deliberately consider your application for using PATCH requests,
and make sure that they are idempotently implemented if needed. If not, use PUT requests.
이것은 아마도 여기에서 읽을 가장 중요한 팁 중 하나 일 것입니다. 이 저장소에서 배워야 할 것이 있다면, 이것이 바로 이루어져야합니다! 이것에 대한 협상이 없습니다.
로그, 모니터링 및 경고하는 데 도움이되는 엔지니어는 문제가되기 전에 문제를 진단하고 개선합니다 . 많은 API (Express/Node 기반, Java, Go)는 다음과 같은 것들을 평가하기위한 사전 정의 된 엔드 포인트를 가지고 있습니다.
`/health`
`/metrics`
로깅이 활성화되지 않았고 잠재적 인 문제가 발생하는 경우 원산지를 추적 할 수 없거나 특정 요청에서 문제가 발생하는 위치를 추적 할 수 없습니다.
모니터링을 활성화하지 않은 경우 분석 관점에서 몇 가지 문제 나 오류가 발생하는 빈도를 알지 못할 것입니다. 그러면 가능한 해결책을 생각하지 못하게합니다.
그리고… 경고가 활성화되지 않으면 고객 (또는 더 나쁘게)이보고 할 때까지 문제가 있는지 알 수 없습니다.
Pagination은 여러 응답에서 컨텐츠 버킷을 만드는 데 도움이됩니다 . 이러한 종류의 최적화는 고객에게 전송/표시되는 데이터를 유지하면서 응답을 개선하는 데 도움이됩니다. 결과의 복잡성을 줄이는 데 도움이되는 응답을 표준화, 세그먼트 및 제한 할 수 있으며 고객이 요청한 것에 대해서만 응답/결과를 제공하여 전반적인 고객 경험을 향상시킬 수 있습니다.
우리는 API가 놀랍고, 성능에 적절하게 최적화되고 향상되면 비즈니스와 고객에게 훌륭한 경험을 제공하는 데 매우 강력 할 수 있다는 것을 알고 있습니다. 비즈니스 요구 사항과 고객 기대는 항상 시간이 지남에 따라 발전합니다. 그리고 책임있는 엔지니어로서, 우리의 목표를 달성하고 초과하는 데 도움이 될 수있는 능력으로 API를 구축하는 방법을 결정하는 것은 우리에게 달려 있습니다.
이 팁은 빙산의 일각에 불과하며 일반적인 환경에서 모든 API에 적용됩니다. 특정 API 및 사용 사례, 상호 작용하는 서비스, 호출 얼마나 자주 호출되는지, 호출되는 위치 등에 따라 이러한 팁을 다른 방식으로 구현해야 할 수도 있습니다.
Laravel- 여권으로 API를 휴식하십시오
PHP -OOPS로 API를 휴식하십시오
파이썬 - 플라스크로 API를 휴식하십시오
Python -Django -RestFramework와 함께 REST API
GO -MUX와 함께 API를 휴식하십시오
Go -Gin과 함께 API를 휴식하십시오
nodejs -Express- 기본으로 API를 휴식하십시오
Nodejs- Express -JWT -Sequellze -Advance와 함께 API를 REST API
몇 분 안에 REST API를 매우 쉽게 만들 수 있으므로 언어 및 프레임 워크 기본 설정에 따라 위의 코드 기반을 선택하고 지침을 따라 REST API를 만들 수 있습니다.
행복한 코딩?
LinkedIn : https://www.linkedin.com/in/the-startup-cto/
중간 : https://apige.medium.com/
트위터 : https://twitter.com/htngapi