웹 개발은 지난 몇 년 동안 대폭 변경되었습니다.
페이지를 렌더링하고 클라이언트로 보내기 위해 템플릿 엔진을 사용하는 데 사용되는 웹 사이트. 일반적으로 XML을 사양 언어로 사용하는 다른 서버에서 정보를 검색하는 SOAP 프로토콜이있었습니다.
나중에 RESTful이 나타났고 사람들은 JSON과 함께 사용하기 시작했습니다. 요즘 RESTful은 원격 부분 만이 아닌 전체 웹 사이트를 제어하는 것입니다. 게시물 표시, 게시물 목록, 사용자 데이터 등을 표시하는 것은 모두 서버 렌더링 표현 대신 RESTful에 의해 수행됩니다. 요즈음 RESTful은 서버에 연결하고 일부 데이터를 검색해야 하는 웹 개발 및 기타 소프트웨어에서 매우 중요하며, 이러한 중요성은 최상의 품질을 달성하고 시스템의 유지 관리.
RESTful API를 개발 한 경험에서 저는 많은 문제에 직면했고 계속하는 동안 몇 가지 정보를 얻었습니다. 여기에서 제가 배운 내용과 RESTful API를 설계하는 방법 및 자주 묻는 질문에 대한 답변을 공유합니다.
https://dev.to/adnanbabakan/best-restful-api-practices-and-tools-1pbh
RESTful이란 무엇입니까?
RESTful은 소프트웨어가 데이터를 검색 할 수 있는 엔드 포인트를 설계하는 아키텍처 스타일입니다. RESTFul API는 많은 프로그래밍 언어에서 쉽게 읽을 수 있으므로 일반적으로 JSON 데이터를 반환합니다.
JSON 이외의 것을 반환 할 수 있습니까?
기술적으로 말하면 그렇습니다! RESTful은 디자인의 패턴 일 뿐이며 특별히 JSON을 사용하도록 만들지는 않습니다. RESTful API는 일반 텍스트, XML, CSV 또는 기타 형식을 반환 할 수 있지만 커뮤니티에서 이미 JSON을 선택 했으므로 계속하는 것이 좋습니다. RESTful API를 디자인하는 데 사용되는 많은 도구는 엔드 포인트가 JSON 만 반환한다고 가정합니다.
RESTful API의 작동 방식에 대한 자세한 내용은 https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven을 참조하십시오. 이 정보는 다음 덕분에 여기에 추가됩니다.
RESTful API 서버를 설계하는 방법은 무엇입니까?
RESTful API 서버는 거의 모든 백엔드 프로그래밍 언어를 사용하여 설계 할 수 있습니다. 이 기사의 뒷부분에서 이에 대해 설명합니다. 여기서 우리는 RESTful API의 패턴을 이해하려고 합니다. 응용 프로그램에서 일반적으로 필요한 것은 CRUD의 기능입니다. CRUD는 만들기, 읽기, 업데이트 및 삭제를 나타냅니다. 이것은 모든 응용 프로그램에 있는 네 가지입니다. 게시물 작성, 게시물 읽기, 게시물 업데이트, 마지막으로 게시물 삭제와 같습니다.
RESTful API에서는 / posts라는 경로 (경로)를 만듭니다. 일반적인 명명 규칙은 복수형을 사용하는 것입니다. CRUD에는 4 개의 작업이 있으므로 이 경로에도 4 개의 작업을 할당해야 합니다. HTTP 프로토콜에는 POST, GET, PUT, DELETE의 네 가지 방법이 있습니다. 이러한 메서드는 각각 CRUD 작업에 사용할 수 있습니다. 다음은 그 예입니다.
GET /posts # Get the posts list
GET /posts/{id} # Get the post with id of {id}
POST /posts # Create post
PUT /posts/{id} # Update the post with id of {id}
DELETE /posts/{id} # Delete the post with id of {id}/post와 같은 경로 접두사는 종종 컬렉션이라고도합니다.
/posts에 /p와 같은 축약 된 경로 이름을 사용하지 마십시오. 이것은 엔드 포인트가 하는 일을 기억하기 어렵게 만듭니다.
경로 이름에 동사를 사용하지 마십시오. 이는 다음 경로가 좋은 RESTful API로 간주되지 않음을 의미합니다.
POST /createPost
POST /deletePost
POST /updatePostHTTP 메서드는 POST, PUT 및 DELETE와 관련하여 크게 다르지 않습니다. 그러나 모든 경로에 POST를 사용하면 모호합니다.
왜 복수형 명사를 사용해야 합니까?
단수 형식을 사용하면 혼란스러울 수 있습니다. 경로 / post를 사용하지만 모든 게시물을 수신한다고 상상해보십시오! 말이 안 돼!
경로명에 동사를 사용하지 않는 이유는 무엇입니까?
경로 이름에 동사를 사용하면 API 끝 점이 필요한 것보다 훨씬 더 많아집니다. 그러나 동일한 경로에서 HTTP 메서드를 사용하는 경우 매우 간결하고 이해하기 쉬운 API가 있습니다.
예를 들어 GET을 사용하여 레코드를 만들 수 있습니까?
다시 기술적으로 말하면 그렇습니다! 그러나 GET 메서드는 일반적으로 데이터 검색에 사용되므로 그렇게 해서는 안됩니다. 주의를 기울여도 해당 게시물의 데이터를 가져 오기 위해 "게시물 게시"라고 부르는 대신 해당 게시물의 데이터를 얻으려면 "그 게시물 가져 오기"라고 말하는 것이 더 합리적입니다.
중첩
게시물이 있고 해당 댓글도 검색하고 싶다고 가정 해보십시오. 중첩 방법을 사용하여 리소스 (예 : 게시물) 또는 계층 적 상황의 소유물을 나타낼 수 있습니다.
GET / posts / {id}에 대한 경로가 이미 있으므로 아래와 같이 경로 집합을 추가해야 합니다.
GET /posts/{id}/comments # Get all comments of post with id of {id}
GET /posts/{id}/comments/{cid} # Get the comment with id of {cid} of post with id of {id}
POST /posts/{id}/comments # Send a comment belonging to post with id of {id}
PUT /posts/{id}/comments/{cid} # Update the comment with id of {cid} of post with id of {id}
DELETE /posts/{id}/comments/{cid} # Delete the comment with id of {cid} of post with id of {id}질의
항상 특정 리소스의 모든 게시물 또는 모든 데이터를 가져와야 하는 것은 아닙니다. 때로는 필터링, 정렬 또는 페이지 매기기가 필요합니다. 백엔드 코드에서 이 작업을 수행하는 방법이 중요하다는 사실에도 불구하고 엔드 포인트를 더 명확하게 만들기 위해 몇 가지 규칙을 따라야 합니다.
마지막으로 쿼리가 있는 경로는 다음과 같아야 합니다.
GET /posts/?page=1&limit_per_page=20&order_by=date&order=desc대신 :
GET /posts/?p=1&lpp=20&&o=date:desc에러
작업이 성공적으로 완료 될 때마다 코드 200으로 응답을 반환합니다. 경로를 찾을 수 없을 때마다 코드 400으로 응답을 반환합니다. 일부 프로그래머는 이 작업을 잊고 HTTP 응답 자체 대신 JSON 응답에서 결과를 다음과 같이 언급합니다. 잘. 코드를 반환하면 응답을 훨씬 쉽게 처리 할 수 있습니다. 다음은 표준 HTTP 응답 코드 목록입니다. https://en.wikipedia.org/wiki/List_of_HTTP_status_codes
오류에는 사람이 읽을 수 있는 메시지와 나중에 사용하기 위해 애플리케이션 만 이해할 수 있는 도메인 별 메시지도 포함되어야 합니다. 예를 들어 다음은 오류 메시지 일 수 있습니다.
HTTP/1.1 403 Forbidden
...
{
"status": 403,
"err_code": "permission_denied",
"message": "User doesn't have enough privileges"
}내결함성 API는 서버 또는 언어에서 생성 된 오류 메시지를 반환해서는 안됩니다. 오류가 발생하면 오류를 처리하고 (예 : try / catch 블록 사용) 적절한 JSON 응답을 반환합니다.
API 버전 지정
시간이 지남에 따라 일부 API 기능을 변경해야 할 수 있습니다. 이것은 그것을 사용하는 응용 프로그램을 손상 시킬 수 있습니다. 따라서 이 문제 버전의 API를 방지하고 이전 API를 모두 새 API로 교체 할 때까지 이전 API가 잠시 그대로 유지되도록 하십시오. 이를 수행하는 가장 많이 사용되는 방법 중 하나는 모든 API 끝점에 버전을 접두사로 붙이는 것입니다. 예를 들면 :
/api/v1/postRESTful API 서버를 설계하기 위해 어떤 언어 / 프레임 워크 및 데이터베이스를 사용해야 합니까?
앞서 언급 했듯이 RESTful은 일반적으로 허용되는 패턴 일 뿐이며 언어 별 패턴이 아닙니다. 따라서 선호하는 언어 / 프레임 워크를 사용하여 RESTful API 서버를 설계 할 수 있습니다.
제가 이 글을 쓰는 동안 정말 흔한 것은 Express 프레임 워크입니다. Express를 사용하여 RESTful API를 만드는 것은 매우 쉽고 빠릅니다. Express는 Node.js 위에 구축되었으므로 이 프레임 워크를 활용하려면 JavaScript를 알아야 합니다.
또 다른 옵션은 Laravel이 될 수 있습니다. 라 라벨은 인증 및 라우팅과 같이 즉시 사용 가능한 RESTful API에 필요한 거의 모든 자산을 제공합니다. Laravel은 PHP로 작성되었습니다.
이러한 언급 된 프레임 워크는 완전히 개인적인 의견입니다. 다른 옵션을 계속 사용할 수 있습니다. 나는 많은 옵션을 시도하고 작업하기 쉽고 재미 있다는 것을 알았기 때문에 이것을 언급했습니다.
데이터베이스는 애플리케이션을 작성할 때 큰 문제가 될 수 있습니다. RESTful API 서버도 예외는 아닙니다. 데이터베이스는 빠르고 유지 관리가 가능해야 합니다. 애플리케이션의 필요에 따라 데이터베이스를 선택해야 합니다. 데이터베이스 측 관계가 필요한 경우 MySQL 또는 PostgreSQL과 같은 RDBMS를 사용해야 합니다. 데이터베이스를 수평 적으로 확장 할 계획이라면 MongoDB를 선택하는 것이 좋습니다.
RESTful API를 디자인 할 때 반드시 하나의 프로그래밍 언어 / 프레임 워크로 수행 할 필요는 없습니다. 접근 방식은 여러 언어로 작성된 마이크로 서비스 일 수 있습니다. 용도에 따라 여러 데이터베이스가 필요하거나 특정 상황에서 유용한 라이브러리 또는 성능에 따라 여러 프로그래밍 언어가 필요할 수 있습니다. 여기에서 마이크로 서비스가 도움이 될 수 있습니다.
이미지 공유 및 처리 웹 사이트를 위한 API를 디자인하도록 배정되었고 매우 빠른 속도를 원하고 백엔드 코드로 Express / Node.js를 선택한다고 가정 해보십시오. 그러나 Python에는 AI 또는 이미지 처리를 위한 좋은 라이브러리가 많이 있다는 것을 알고 있습니다. 여기에서 Python을 마이크로 서비스로 구현하여 기본 API 서버를 완성 할 수 있습니다.
API 서버 테스트
API 서버를 설계하는 동안 (RESTful이든 아니든) 새 경로를 만들거나 이전 경로를 변경할 때마다 테스트 해야 합니다. 매번 브라우저를 다시 로드하거나 HTML을 사용하여 양식을 만들어 사용자 지정 헤더와 함께 데이터를 앞뒤로 보내는 것은 불가능합니다. 따라서 필요한 것은 API 테스트 소프트웨어입니다. 많은 도구가 있지만 일반적으로 사용하는 것을 선호하는 것은 Postman입니다. 무료이며 간단합니다.
Postman은 모든 HTTP 메소드, 사용자 정의 헤더, 매개 변수 등을 포함하여 API를 테스트하는 데 필요한 모든 종류의 기능을 제공합니다. JSON 응답을 예쁘게 만들고 여러 언어와 cURL로 정의한 대로 HTTP 요청을 만드는 데 필요한 코드를 생성합니다.
등록된 댓글이 없습니다.
