[api] REST API 모범 사례 : 매개 변수 값 목록을 입력으로 승인하는 방법 [닫기]

한 걸음 물러서

무엇보다도 REST는 URI를 범용 고유 ID로 설명합니다. 너무 많은 사람들이 URI의 구조와 어떤 URI가 다른 URI보다 “휴식 적”인지에 따라 잡히고 있습니다. 이 주장은 누군가 “Bob”을 명명하는 것이 “Joe”를 명명하는 것보다 낫다고 말하는 것만 큼 성가신 일입니다. 두 사람 모두 “사람을 식별하는”직무를 수행합니다. URI는 보편적으로 고유 한 이름에 지나지 않습니다 .

따라서 REST의 눈 ?id=["101404","7267261"]에는 더 편안한 지 ?id=101404,7267261또는 \Product\101404,7267261다소 쓸데 없는지 에 대한 논쟁 이 있습니다 .

이제 URI를 구성하는 방법이 여러 번 RESTful 서비스의 다른 문제에 대한 좋은 지표가 될 수 있다고 말했습니다. URI에는 일반적으로 몇 가지 붉은 깃발이 있습니다.

제안

1. 동일한 리소스 및 Content-Location

   우리는 두 가지 스타일을 모두 수용하고 싶을 수도 있지만 유연성으로 인해 실제로 혼란과 유지 보수 (유지 관리, 문서 등)가 더 많이 발생합니까?

   URI는 리소스를 식별합니다. 각 자원에는 하나의 표준 URI 가 있어야 합니다. 이 두 URI를 동일한 리소스를 가리 가질 수 없습니다 것을 의미하지 않는다 하지만 그 일에 대해 갈 수있는 잘 정의 된 방법이 있습니다. JSON 및 목록 기반 형식 (또는 다른 형식)을 모두 사용하기로 결정한 경우 이러한 형식 중 어떤 것이 기본 정식 URI 인지 결정해야합니다 . 동일한 “자원”을 가리키는 다른 URI에 대한 모든 응답에는 Content-Location헤더 가 포함되어야합니다 .

   유추라는 이름을 고수하면서 여러 URI를 갖는 것은 사람들의 별명을 갖는 것과 같습니다. 그것은 완벽하게 수용 가능하고 종종 매우 편리하지만, 닉네임을 사용하는 경우 여전히 그 사람의 이름을 알고 싶어 할 것입니다. 이런 식으로 누군가 “Nichloas Telsa”라는 이름으로 누군가를 언급 할 때, 나는 그들이 “Nick”이라고 언급 한 사람에 대해 이야기하고 있다는 것을 알고 있습니다.

2. URI에서 “검색”

   더 복잡한 경우는 더 복잡한 입력을 제공하려는 경우입니다. 예를 들어 검색시 여러 필터를 허용하려는 경우 …

   내 경험의 일반적인 규칙은 URI에 동사가 포함되어 있으면 무언가 꺼져 있다는 표시 일 수 있습니다. URI의 자원을 식별, 그러나 그들은 표시 안 무엇을 우리가 자원하고 있어요. 이것이 바로 “일관된 인터페이스”라는 HTTP 또는 편안한 용어입니다.

   URI에서 동사를 사용하는 것은 비유라는 이름의 유사점을 극복하기 위해 누군가와 상호 작용할 때 누군가의 이름을 변경하는 것과 같습니다. Bob과 상호 작용하는 경우 Bob에게 Hi라고 말하고 싶을 때 Bob의 이름이 “BobHi”가되지 않습니다. 마찬가지로 제품을 “검색”하려는 경우 URI 구조가 “/ Product / …”에서 “/ Search / …”로 변경되지 않아야합니다.

초기 질문에 답변

1. ["101404","7267261"]vs 관련 101404,7267261: 여기에 제 제안은 단순성을 위해 JSON 구문을 피하는 것입니다 (즉, 사용자가 실제로 필요하지 않은 경우 URL 인코딩을 수행하지 않아도 됨). API를 좀 더 유용하게 사용할 수 있습니다. 더 나은 방법은 다른 사람들이 권장 한 application/x-www-form-urlencoded것처럼 최종 사용자에게 가장 친숙 할 수 있는 표준 형식을 사용하는 것입니다 (예 🙂 ?id[]=101404&id[]=7267261. “pretty”가 아닐 수도 있지만 Pretty URI가 필요한 URI를 의미하지는 않습니다. 그러나 궁극적으로 REST에 대해 말할 때 내 초기 요점을 되풀이하는 것은 중요하지 않습니다. 그것에 너무 많이 머 무르지 마십시오.

2. 복잡한 검색 URI 예제는 제품 예제와 거의 같은 방식으로 해결할 수 있습니다. application/x-www-form-urlencoded이미 많은 사람들에게 익숙한 표준이므로 형식을 다시 사용하는 것이 좋습니다 . 또한 두 가지를 병합하는 것이 좋습니다.

URI …

/Search?term=pumas&filters={"productType":["Clothing","Bags"],"color":["Black","Red"]}

URI 인코딩 후 URI …

/Search?term=pumas&filters=%7B%22productType%22%3A%5B%22Clothing%22%2C%22Bags%22%5D%2C%22color%22%3A%5B%22Black%22%2C%22Red%22%5D%7D

로 변환 할 수 있습니다 …

/Product?term=pumas&productType[]=Clothing&productType[]=Bags&color[]=Black&color[]=Red

URL 인코딩 요구 사항을 피하고 상황을 좀 더 표준으로 보이게하는 것 외에도 이제 API를 약간 균질화합니다. 사용자는 제품 또는 제품 목록을 검색하려는 경우 (모두 RESTful 용어로 단일 “자원”으로 간주 됨) /Product/...URI에 관심이 있다는 것을 알고 있습니다 .

답변

--------------------------------------------
Book #1
--------------------------------------------
    Title: The return of the amazing monster
    Summary:
    Pages:
    Publisher:
--------------------------------------------

---------------------------------
The return of the amazing monster
---------------------------------
Summary:
Pages:
Publisher:
---------------------------------

/products/{id}
/products/{id}/specs/{name}

/products?ids=