2017-10-17 12 views
0

저는 node.js를 처음 사용하고 있으며 내 첫 번째 node.js 안정적인 API를 hapi.js 프레임 워크에 내장했습니다. 모든 서비스는 기본적으로 데이터베이스 쿼리를 수행합니다. 서비스의 예는 다음과 같다 : 서비스를 호출안정적인 API를 구축 할 때 선택해야하는 HTTP 방법

let myservice = { 
    method: "POST", 
    path: "/updateRule", 
    config: { 
     handler: (request, reply) => { 
      updateRule(request.payload) 
      .then((result) => { 
       reply(successResponse(request, result)); 
      }) 
      .catch((err) => reply(failResponse(request, err)).code(500)); 
     }, 
     validate: { 
      payload: { 
       ruleId: joi.number().required(), 
       ruleName: joi.string().required(), 
       ruleDesc: joi.string().required() 
      } 
     }, 
     auth: "jwt", 
     tags: ["api", "a3i"] 
    }, 
} 

updateRule(input): Promise<any> { 
     return new Promise((resolve, reject) => { 
      let query = `select a3i.update_rule(p_rul_id := ${input.ruleId}, p_rul_name := '${input.ruleName}', p_rul_desc := '${input.ruleDesc}')`; 
      postgresQuery(lbPostgres, query, (data, commit, rollback) => { 
       try { 
        let count = data.rows[0].update_rule.count; 
        if (count === 1) { 
         let ruleId = data.rows[0].update_rule.result[0]; 
         let payload: SuccessPayload = { 
          type: "string", 
          content: `Rule ${ruleId} has been updated` 
         }; 
         commit(); 
         resolve(payload); 
        } else { 
         let thisErr = new Error("No rule can be found."); 
         thisErr.name = "4003"; 
         throw thisErr; 
        } 
       } 
       catch (err) { 
        rollback(); 
        if (err.name === "4003") { 
         reject(detailError(4003, err.message)); 
        } else { 
         reject(detailError(4001, err.message)); 
        } 
       } 
      }, reject); 
     }); 
    } 

당신이 볼 수 있듯이, 그것은 데이터베이스 테이블에서 데이터베이스 호출 (쿼리) 및 업데이트 지정된 행을 불러 일으킨다. 마찬가지로 createRule/deleteRule이라는 다른 서비스가 데이터베이스 테이블에서 레코드를 만들거나 삭제하고 있습니다. 제 생각에 서비스 간의 차이점은 다른 데이터베이스 쿼리를 수행하고 있습니다. 나는이 게시물 PUT vs. POST in REST을 읽었지만 나의 경우에는 POST와 PUT의 차이를 볼 수 없었다.

여기 내 질문은 :

  1. 내가이 경우 어떤 HTTP 방법을 사용 하는가?

  2. 대부분의 안정적인 API 예 (예 : https://www.codementor.io/olatundegaruba/nodejs-restful-apis-in-10-minutes-q0sgsfhbd)는 동일한 "리소스"에 대해 다른 작업을 수행하기 위해 다른 HTTP 메소드를 사용하는 동일한 URL을 사용합니다. 제 생각에는 대개 데이터베이스 테이블입니다. 하나의 URL에 하나의 HTTP 메소드 만 있고 하나의 유형의 조작 만 수행하는 것과 비교하면이 아키텍처의 이점은 무엇입니까?

이 질문은 문제를 언급하지 않으며 구체적이지 않습니다. 어떤 사람들은 투표를하지 않을 수 있습니다. 그러나 초보자로서 나는 전형적인 Restful API가 무엇인지 알고 정말로 API가 "best practice"인지 확인하고 싶습니다. 도와주세요!

답변

2

리소스가 이미 있으므로 정확한 리소스에 대한 특정 URI가 있고 업데이트하려는 경우 PUT을 사용하십시오.

리소스가 아직 존재하지 않고 리소스를 만들려는 경우 서버에서 새 리소스를 나타내는 URI를 선택하게하려면 POST를 사용하고 POST URI는 일반적인 "새 리소스 만들기"URI가됩니다. 특정 리소스에 대한 URI가 아니며 해당 리소스를 나타내는 URI를 만듭니다.

호출자가 새 리소스를 나타내는 리소스 URI를 만들 경우 PUT을 사용하여 새 리소스를 만들 수도 있습니다. 이 경우 새 리소스로 PUT하고 해당 URI가있는 리소스가 이미 있으면 업데이트되고 그렇지 않은 경우 리소스가 만들어집니다.

두 가지를 모두 지원할 필요는 없습니다. 당신은 하나 또는 다른 것을 사용하는 방식으로 API를 작동하도록 결정할 수 있습니다. 특정 경우


, 이미 이미 당신이 행을 나타내는 특정 URI에 PUT을하고있는 존재하기 때문에 거의 항상 PUT 될 존재하는 데이터베이스에서 특정 행의 갱신 .

하나의 URL이 하나의 HTTP 메소드 만 가지며 한 가지 유형의 조작만을 수행하는 것과 비교하면이 아키텍처의 이점은 무엇입니까?

API를 어떻게 표현할 것인가는 여러분에게 달려 있습니다., 어떤 경우에는

resource identifier 
data 
method 

, 메소드가 GET에 의해 포섭 할 수 있습니다, PUT, POST를 PUT 또는 DELETE 그래서 당신은 단지 자원 식별자, 데이터를 필요 GET : REST 뒤에 일반적인 개념은 여러 구성 요소를 가지고있다 POST 또는 DELETE.

다른 경우 또는 다른 디자인에서이 방법은 PUT 또는 POST에서 표현할 수있는 것보다 더 자세합니다. 따라서 URL에 실제로 메소드가있어서 PUT과 POST를 구별하지 않아도됩니다 만큼.

예를 들어, 조치는 "구매"일 수 있습니다. 메소드가 나머지 URL에 의해 암시 된 POST에서이를 캡처 할 수는 있지만, 명확한 설명을 위해 /buy이라는 메소드가있는 URL에 실제로 POST하려는 경우 다른 동일한 엔드 포인트 접두어를 사용할 수 있습니다 /addToCart 등의 메소드 ... 실제로는 객체가 REST 디자인에 어떤 영향을 미치고 어떤 작업을 표면에 적용할지에 따라 달라집니다. 때로는 객체가 GET, PUT, POST 및 DELETE에 적합 할 때가 있고 때로는 해당 리소스에서 수행 할 특정 작업에 대한 자세한 정보가 URL에 필요하기도합니다.

+0

서비스 경로에 매개 변수를 추가해야하므로 모든 리소스 (데이터베이스 테이블의 행)에 해당 URL이 있어야합니다. 예를 들어 레코드에 대한 작업을 수행하려면 고유 ID를 url의 매개 변수로 전달해야합니다. 이게 옳은 거니? – zhangjinzhou

+0

@zhangjinzhou - 그게 RESTful 방법이 될 것입니다. GET, PUT 또는 DELETE의 각 URI는 고유 한 자원을 나타내야합니다. – jfriend00

+0

네 맞습니다. 그리고 그것은 URL의 선택적 매개 변수로 정의됩니다. – Silencer310

1

휴식을 원하면 PostGet을 사용할 수 있습니다. > 포스트

  • 읽기 - ->
  • 업데이트 받기 -> 넣어 또는 패치
  • 삭제 -> 삭제 당신이 Restfull 싶은 경우

    • 만들기 , 당신은 CRUD에 방법을 기반으로합니다

    동일한 URL에있는 메소드를 사용하여 전체 API를 작성하면 빌드/이해하기가 더 쉬울 수 있습니다. user에 대한 모든 검색어는 user/get, user/add, user/update이 아닌 user URL에 있습니다. URL이 너무 많지 않아도 동일한 기능을 사용할 수 있습니다.

    API를 만들 때 통계 분석 및 기타 작업을 위해 몇 가지 로그가 필요할 수 있습니다. 이렇게하면 메서드로 분할하는 경우 몇 개의 게시 요청 또는 가져 오기 요청을 기록 할 수있는 필터 만 있으면됩니다.

    실제로 Get 요청으로 만 API를 작성할 수 있습니다. 그러나 방법과 URL을 spliting은 (너무 많은 작업 이름 또는 URL) 단지의 URL을 방지하고 API를 통해가는 모든 요청을 기록 할 수있는 가장 쉬운 방법이 가장 좋은 방법입니다

    enter image description here - 목록 항목

    • 레벨 1이고 나머지

    • 레벨 2 Restfull

    • 레벨 3

    • Hateoas이다

    당신은 내가 일반적으로 할 것은 새로운 자원을 만들기위한 "POST"를 사용하고, 이미 존재하는 자원을 업데이트하기위한 "PUT"를 사용하다 마틴 파울러

  • +0

    게시물 주셔서 감사합니다. 다양한 레벨이 매우 유용합니다! GET은 파일을 업로드하거나 스트림이나 다른 것을 넘겨 줄 수 있기 때문에 일반적으로 API를 빌드하기에 충분하지 않다는 것을 알고 있습니다. 그러나 POST/PUT을 사용하여 리소스를 생성/업데이트 할 때 어떤 차이점도 보이지 않습니다. – zhangjinzhou

    +0

    식별자를 지정하지 않고 POST를 사용하는 것과 같이 PUT을 사용하여 새 리소스를 만들 수 없습니까? – zhangjinzhou

    +0

    예, 이런 식으로 넣을 수 있습니다 – sheplu

    0

    에 의해 쓰여진 어떤 책이나 기사를 내 더 많은 정보를 찾을 수 있습니다.

    두 번째 질문에 대해 대부분의 API는 동일한 URL에서 동일한 리소스에서 다른 작업을 수행합니다. 이는 보안 때문에 (예 :/삭제) URL에서 수행중인 작업을 노출하고 싶지 않기 때문일 수 있습니다. 또한 많은 프레임 워크는 리소스 (객체 클래스)에 대한 자동 URL을 생성 한 다음 요청 메소드에서 차별화합니다. 사람들은 단지 맞춤 URL을 사용하지 않는 경향이 있습니다.