5 Express를 사용한 현대 API 구축 모범 사례

Express의 시작과 운행은 상대적으로 간단하다.또한 유연성을 제공하기 때문에 프레임워크를 선택하여 API를 구축할 때 유행하는 선택이다.따라서 Express를 사용하여 API를 구축하는 방법을 알려주는 많은 강좌와 강좌가 있지만, 검증과 오류 응답 등에서 어떤 최선의 실천을 고려해야 할지 확신할 수 없습니다.
다음 모범 사례는 Express를 사용하여 새로운 API를 설계하고 기존 API를 개선하는 데 도움이 됩니다.이러한 모범 사례는 Express의 기존 기능은 아니지만 다른 newer frameworks의 일부 기능을 제공합니다.우리 곤경에 빠지자!

1. async 및 await의 충분한 사용 활성화
만약 중간부품이나 루트 처리 프로그램에서 async과 await을 사용한다면 Express는 기술적으로 정상적으로 작동할 수 있지만, 대기 약속이 거부되었을 때 던진 오류를 포착하기 위해 추가 코드를 작성해야 하며, 이 오류를 사용하여 next() 함수를 호출해야 한다.만약 이렇게 하지 않는다면 요청이 끊기고 클라이언트에게 응답을 보내지 않을 수도 있습니다.상당히 혼란스러워질 수도 있고 잊기 쉽다.
express-async-errors 패키지는 async과 await을 사용하여 모든 잠재적인 오류를 포획하고 처리할 수 있도록 해 줍니다. 이 패키지는 자동으로 모든 것을 완성할 수 있기 때문입니다.그것은 어떤 설정도 필요하지 않습니다: express 이후에 그것을 필요로 한다면 당신은 시작할 수 있습니다!

2. JSON 모드를 사용하여 요청 데이터 검증
요청에 API로 보내는 데이터만 신뢰해서는 안 됩니다. 오류가 쉽게 포함될 수도 있고, 더 나쁘게도 악성 데이터가 포함될 수도 있습니다. 이 데이터는 공격자가 프로그램을 붕괴시키거나 데이터를 훔치기 위해 정성들여 작성한 것입니다.즉, API로 전송된 데이터를 항상 확인한 다음 데이터베이스에 저장하는 등의 다른 작업을 수행해야 합니다.
JSON Schema은 사용자가 데이터를 사용하고자 하는 형식인 '모드' 를 설명할 수 있는 표준입니다.패턴에 따라 데이터를 검증하지 못하면 자세한 오류 메시지가 표시되고 API 응답에서 클라이언트에 전달될 수 있습니다.JSON 모드는 매우 강력해서 복잡한 데이터 구조를 검증하는 모드를 만들 수 있습니다. 그러나 모드는 데이터가 문자열인지 확인할 수 있습니다. 모드는 다음과 같습니다.

{ "type": "string" }

express-json-validator-middleware 패키지는 JSON 모드에 대한 지원을 응용 프로그램에 도입하여 정의된 모드에 따라 API에 대한 요청을 검증하고 사용할 수 있도록 구성합니다.패키지 설명서의 Example Express app은 API에 사용할 수 있는 아주 좋은 예제를 제공합니다.

3. 기존 오류 응답 형식 사용
API를 구축할 때 자신의 오류 응답 형식을 쉽게 발명할 수 있지만 HTTP response status codes은 각각 특정한 오류 상태를 전달하기 때문에 좋은 출발점이다.이 외에 다른 상하문을 제공하여 오류가 발생한 원인과 클라이언트 오류가 발생한 상황에서 어떤 조치를 취해 문제를 해결할 수 있는지 설명해야 한다면 application/problem+json규범을 적용하는 것을 고려할 필요가 있습니다.이것은 HTTP API 오류 응답 형식에 대한 권장 사양으로, 이는 사용자가 자신의 오류 응답 형식을 제시하지 않아도 된다는 것을 의미합니다.다음은 이 형식을 사용하는 응답 예입니다.

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json
Content-Language: en

{
    "type": "https://example.net/validation-error",
    "title": "Your request parameters didn't validate.",
    "invalid-params": [
        {
            "name": "age",
            "reason": "must be a positive integer"
        },
        {
            "name": "color",
            "reason": "must be 'green', 'red' or 'blue'"
        }
    ]
}

이 형식으로 오류 응답을 보내는 것에 대한 더 자세한 정보는 규범 초안:RFC7807 – Problem Details for HTTP APIs을 보십시오.

4. 웹 페이지에서 API를 호출할 수 있도록 CORS 응답 헤더를 보냅니다.
웹 페이지의 프런트엔드 JavaScript에서 API에 요청을 보내려면 일반적으로 API가 응답에 CORS(소스 간 공유) 헤더를 보내야 합니다.이 제목들은 웹 브라우저가 API 응답 내용에 접근할 것을 요청한 웹 페이지가 정상적인지 알려 줍니다.
응용 프로그램에 cors 중간 패키지를 추가하여 API 끝에서 올바른 CORS 응답 헤더를 보낼 수 있습니다.기본적으로 이 제목은 모든 웹 페이지가 API에 요청할 수 있도록 하기 때문에 configuration options을 확인하고, 최소한 origin 옵션을 설정해서 어떤 웹 페이지가 당신의 API를 호출할 수 있는지 제한하십시오. (공용으로 실행되는 API가 아니면 문제가 되지 않습니다.)

5. 너의 걱정을 떼어놓다
모든 유형의 소프트웨어를 구축할 때 이것은 중요한 설계 원칙이다. 코드를 서로 다른 모듈로 나누어 단일한 용도와 정의가 좋은 인터페이스를 가진다.Express를 사용하여 API를 구축할 때 하나의 모듈에 여러 개의 관심사를 혼합하기 쉽다. 예를 들어 Express 응용 프로그램 설정, 루트 정의, 루트 처리 프로그램 중간부품, 데이터베이스 호출 등이다.단지 네가 이 점을 할 수 있기 때문에 네가 마땅히 해야 한다는 것은 결코 의미하지 않는다.이러한 방식으로 응용 프로그램을 구축하면 당신의 코드를 미래에 더욱 테스트, 디버깅, 유지보수와 확장하기 어려울 것입니다.

If you want to see what a clear separation of concerns can look like for an Express based API, sign up to my mailing list and I’ll send you a link to the code for an example application which demonstrates this.

물론 앞으로 응용 프로그램을 재구성하고 관심사를 분리하는 것은 가능하지만, API를 기획하고 디자인할 때 가능한 한 빨리 재구성하는 방법을 고려할 수 있다면 미래의 개발에 더욱 안정적인 기반을 마련할 수 있을 것이다.