Open API와 API Key 종합퀴즈 문제풀이

문제1. 영화 예매 사이트를 개발하고 있습니다. API를 작성하며 잔여 좌석을 확인하는 GET /inquiry라는 엔드포인트를 만들었는데, REST 원칙을 준수하지 않았다는 지적을 받았습니다. 그 이유로 가장 적절한 것을 고르세요.

A. HTTP 메서드 중 GET 보다 PUT을 사용하는 것이 적절하기 때문이다.

B. 엔드포인트에 동사를 사용했기 때문이다.

C. 엔드포인트에 좌석에 대한 리소스를 지칭하지 않았기 때문이다.

D. 응답에 Location 헤더 정보를 전달하지 않았기 때문이다.

A. HTTP 메서드 중 GET 보다 PUT을 사용하는 것이 적절하기 때문이다.
HTTP 메서드는 자원에 대한 요청에 적절한 메서드를 사용하는 것이 중요하다. GET 메서드는 자원의 정보를 조회하는 목적으로 사용되며, PUT 메서드는 자원의 정보를 수정하는 목적으로 사용된다. 좌석 정보는 조회하는 목적으로 사용되므로 GET이 적절하다.

B. 엔드포인트에 동사를 사용했기 때문이다.
REST API에서는 동사를 사용하지 않고, 자원을 지칭하는 명사만 사용하는 것이 좋다. 하지만 동사만 사용한 엔드포인트를 사용하는 것만으로는 REST 원칙을 준수하지 않은 것으로 판단할 수 없다.

RESTful API는 리소스의 상태를 나타내는 URL(Uniform Resource Locator)에 대한 규칙을 정하는 것이 목적이다. RESTful API의 주소는 리소스를 표현해야 하며, 동사는 사용하지 않는 것이 좋다. 예를 들어, 잔여 좌석에 대한 정보는 GET /seats/available로 표현하는 것이 좋다.

C. 엔드포인트에 좌석에 대한 리소스를 지칭하지 않았기 때문이다.
REST API는 자원(Resource)의 제어(Representation)를 기반으로한 소프트웨어 아키텍처 스타일이다. API 엔드포인트에서 자원을 지칭하는 것이 중요한 REST 원칙 중 하나이다. 따라서 API 엔드포인트에서 좌석에 대한 리소스를 지칭하지 않은 GET /inquiry 엔드포인트는 REST 원칙을 준수하지 않은 것으로 판단될 수 있다.

D. 응답에 Location 헤더 정보를 전달하지 않았기 때문이다.
Location 헤더는 HTTP 응답의 상태 코드가 201(Created) 또는 204(No Content)일 때 사용되는 헤더이다. 새로운 리소스가 생성되었거나 기존 리소스가 수정되었을 때, 새로운 리소스의 위치 정보를 제공하는 헤더이다.
하지만 GET /inquiry는 잔여 좌석을 확인하는 엔드포인트로써, 새로운 리소스를 생성하지 않기 때문에 Location 헤더를 사용할 필요가 없다. 따라서, 응답에 Location 헤더를 전달하지 않는 것은 오류가 아니다.

---

문제2. 요리 레시피를 제공하는 웹사이트를 만들기 위해, 냉장고에 있는 재료 목록을 조회해야 합니다. 엔드포인트로(endpoint)는 어떤 것이 가장 적절한지 고르세요.

A. GET /refrigerator

B. GET /ingredient

C. POST /inquiry

D. POST /recipe

A. GET /refrigerator
/refrigerator는 냉장고를 지칭하며 이에 들어있는 재료에 대한 정보를 조회할 수 있습니다. 다만 오해의 소지는 냉장고 목록을 조회할 수 도 있을것 같다.

B. GET /ingredient             (문제 지문이 애매한것 같다.. A도 답이 될 수 있지 않은가..)
가장 적절한 엔드포인트 이유는 RESTful API에서의 원칙인 HTTP 메서드의 사용과 리소스의 지칭을 준수하기 위함입니다.
GET /ingredient는 재료 목록을 얻는 것이 목적이기 때문에, 올바른 endpoint입니다. 
GET 메서드는 리소스를 조회하는 기능을 가지고 있기 때문에 재료 목록을 조회하는 경우에 적절한 메서드입니다.
(정보를 조회하는 것은 맞지만, 냉장고 안에 있는 재료에 대한 정보를 조회하는 것이므로 /refrigerator가 더 적절한게 아닌가 싶다..)

C. POST /inquiry
POST 메서드는 새로운 리소스를 생성하는 기능을 가지고 있기 때문에 재료 목록을 조회하는 경우에는 적절하지 않습니다.
RESTful API 에서 POST 메서드는 리소스의 상태를 변경하는 것에 사용되는 메서드입니다. 재료 목록을 조회하는 것은 리소스 상태를 변경하지 않는 것이므로, GET 메서드를 사용하는 것이 더 적합합니다.

D. POST /recipe
재료 목록을 조회하는 것에 대한 엔드포인트 이름이 아닙니다. 이 엔드포인트는 요리 레시피를 제출하기 위한 것이 될 것입니다.

---

문제3. 여러분은 트위틀러 웹사이트의 기획을 전달받은 개발자입니다. 데이터베이스에는 트윗이 너무 많으므로, 트윗 목록을 보여주기 위해 무한 스크롤을 이용해 추가적으로 트윗을 불러오려고 합니다. 이때 추가적인 트윗을 불러오기 작성해야 할 엔드포인트(endpoint)로는 어떤 것이 가장 적절한지 고르세요.

 

A. GET /infinite-scroll

B. GET /tweets?offset=10&limit=10

C. POST /more-tweets

D. PUT /tweets

A. GET /infinite-scroll
적절하지 않은 엔드포인트입니다. 스크롤의 무한적 정의가 담겨져 있지 않아 개발자와 클라이언트 사이에 통신 약속이 불충분합니다.

B. GET /tweets?offset=10&limit=10
트윗 목록을 보여주기 위해 무한 스크롤을 사용하려고 하므로, 트윗 목록을 얻기 위한 GET 요청이 가장 적절합니다. offset 매개변수는 트윗의 시작 위치를 나타내고, limit 매개변수는 동시에 불러올 트윗의 수를 나타냅니다. 이렇게 정의한 엔드포인트를 통해 트윗 목록을 요청하고 응답할 수 있습니다.

C. POST /more-tweets
적절하지 않은 엔드포인트입니다. 추가적인 데이터를 전송할 때 사용하는 POST 요청이 아니라 GET 요청이 적절합니다.

D. PUT /tweets
PUT은 데이터의 전체 내용을 교체하는 것이기 때문에, 불필요한 데이터 교체가 발생할 수 있다. 이는 트윗의 데이터 사이즈가 상당히 클 경우, 많은 부하가 발생합니다.

B와 C 두 가지 엔드포인트 모두 사용 가능하지만, B가 더 권장되는 이유는 기존에 정의된 REST API 스타일을 따르는 것이기 때문입니다. B에서는 GET 메소드를 사용하고, 트윗을 불러올 때 offset과 limit 파라미터를 통해 특정 범위의 트윗을 불러오게 하고 있습니다. 따라서 이는 데이터를 안정적으로 처리할 수 있고, 보다 유연한 스크롤을 구현할 수 있어 적합합니다.

문제4. 여러분은 위치 기반 맛집 탐색 앱의 기획을 전달받은 개발자입니다. 특정 위치 기반의 모든 식당 목록을 조회하고, 그중 한식만 필터링하는 기능이 추가됩니다. 해당 요청을 수행하기에 알맞은 엔드포인트(endpoint)로 가장 적절한 것을 고르세요.

 

A. GET /filter/korean
B. GET /restaurants?coordinate=126.9178889,37.5561619&type=korean
C. GET /filter?type=korean
D. GET /get-restaurants?coordinate=126.9178889,37.5561619&type=korean

A. GET /filter/korean

B. GET /restaurants?coordinate=126.9178889,37.5561619&type=korean
이 엔드포인트는 좌표와 식당 종류(한식) 두 가지 기준을 검색 조건으로 사용하기 때문입니다. 좌표는 위치 기반의 앱이므로 중요하고, 종류는 필터링이므로 검색 결과를 제한하는 역할을 합니다. 검색 결과를 제한하기 위한 검색 조건을 가장 잘 나타내는 엔드포인트 입니다.

C. GET /filter?type=korean

D. GET /get-restaurants?coordinate=126.9178889,37.5561619&type=korean

B, C, D 옵션은 위치와 식당 종류를 파라미터로 전달하지만, A 옵션은 한식 종류만 파라미터로 전달하기 때문에 틀렸다. 위치 정보는 검색 결과를 정확히 결정하는 중요한 요소이기 때문에 필수적으로 포함되어야 한다.

---

문제5. 도서 검색 사이트에서 도서 제목을 바탕으로 검색 기능을 구현하려고 합니다. 요청이 REST 원칙에 적합하도록 하려면 어떻게 해야 할지 가장 적절한 것을 고르세요.

요청
GET /books
[헤더 생략]

{ "query": { "title": "code" } }


정상 응답
HTTP/1.1 200 OK
[헤더 생략]
{
	"books": [
		{ "isbn": "9780132350884", "title": "Clean Code", "author": "Robert C.Martin", "price": "$42.47" },
        { "isbn": "0735619670", "title": "Code Complete", "author": "Steve McConnell", "price": "$24.17" }
	]
}

A. 검색이므로 POST 메서드를 사용해야 한다.

B. 검색이므로 PUT 메서드를 사용해야 한다.

C. 검색이므로 PATCH 메서드를 사용해야 한다.

D. GET 요청에는 Query Parameter를 사용해야 한다.

E. GET 요청에는 Path Parameter를 사용해야 한다.

A. 검색이므로 POST 메서드를 사용해야 한다.

B. 검색이므로 PUT 메서드를 사용해야 한다.

C. 검색이므로 PATCH 메서드를 사용해야 한다.

D. GET 요청에는 Query Parameter를 사용해야 한다.
REST 원칙에서 검색 기능은 GET 메서드를 사용해야 하며, 검색 기준인 도서 제목은 Query Parameter로 전달되어야 합니다. 따라서, 도서 검색 사이트에서는 GET 요청에 Query Parameter를 사용해야 합니다.

E. GET 요청에는 Path Parameter를 사용해야 한다.

---

문제6. 다음은 유저가 영화를 보기 위해 좌석을 예매하기 위한 요청과 응답입니다. 다음 빈칸에 들어갈 것으로 옳은 것을 고르시오.

요청
__(ㄱ)__ ____(ㄴ)______ HTTP/1.1
[헤더 생략]
{ "user": "kimcoding" }


정상 응답
HTTP/1.1 201 ___(ㄷ)____
[헤더 생략]
{ 
	"message": "예약이 성공적으로 진행되었습니다",
	"seat" : "g10",
	"user" : "_____(ㄹ)_____"
}


오류 응답
HTTP/1.1 ______(ㅁ)______
[헤더 생략]
{ 
  "message": "예약에 실패했습니다",
  "seat" : "g10",
  "status": "다른 사용자에 의해 예약됨"
 }

A. (ㄱ) GET - (ㄴ) /reserve - (ㄷ) created - (ㄹ) kimcoding - (ㅁ) 503 Service Unavailable
B. (ㄱ) POST - (ㄴ) /seats/g10 - (ㄷ) created - (ㄹ) kimcoding - (ㅁ) 409 Conflict
C. (ㄱ) POST - (ㄴ) /reservation - (ㄷ) OK - (ㄹ) kimcoding - (ㅁ) 409 Conflict
D. (ㄱ) PUT - (ㄴ) /seats - (ㄷ) created - (ㄹ) kimcoding - (ㅁ) 503 Service Unavailable

A. (ㄱ) GET - (ㄴ) /reserve - (ㄷ) created - (ㄹ) kimcoding - (ㅁ) 503 Service Unavailable

B. (ㄱ) POST - (ㄴ) /seats/g10 - (ㄷ) created - (ㄹ) kimcoding - (ㅁ) 409 Conflict
HTTP 메서드는 요청의 종류를 나타내는 것입니다. 여기서는 POST 메서드가 사용되었습니다. POST 메서드는 자원을 생성하는 것을 목적으로 하는 요청입니다.URI는 요청할 리소스의 위치를 나타냅니다. /reservation 에서 /seats/g10로 변경되었습니다. /seats/g10은 g10 좌석을 예약하는 것을 목적으로 하는 URI입니다.

HTTP 응답 상태 코드 201 Created는 요청이 성공적으로 수행되어 새로운 자원이 생성된 것을 의미합니다.

오류 응답에서는 HTTP 상태 코드 409 Conflict이 사용되었습니다. 이 상태 코드는 요청에 대한 처리중 충돌이 발생한 것을 의미합니다. 다른 사용자에 의해 예약된 좌석에 대한 요청에 적합합니다.

C. (ㄱ) POST - (ㄴ) /reservation - (ㄷ) OK - (ㄹ) kimcoding - (ㅁ) 409 Conflict

D. (ㄱ) PUT - (ㄴ) /seats - (ㄷ) created - (ㄹ) kimcoding - (ㅁ) 503 Service Unavailable

---

문제7. 다음은 영화 예매를 위한 요청과 응답입니다. 응답이 REST 원칙에 맞게 수정한 것을 모두 고르세요. (정답 두개)

요청
POST /seats/g10 HTTP/1.1
[헤더 생략]
{ "user": "kimcoding" }


정상 응답
HTTP/1.1 200 OK
[헤더 생략]
{ "message": "예약이 성공적으로 진행되었습니다" }


오류 응답
HTTP/1.1 409 Conflict
[헤더 생략]
{ 
  "message": "예약에 실패했습니다",
  "seat" : "g10",
  "status": "다른 사용자에 의해 예약됨"
 }

A. 정상적으로 생성된 리소스에 대한 정보가 응답에 담겨야 한다.

B. 정상 응답 코드는 201 Created 여야 한다.

C. 오류 응답 코드는 503 Service Unavailable 여야 한다.

D. 응답 메시지는 영문으로 쓰여져야 한다.

A. 정상적으로 생성된 리소스에 대한 정보가 응답에 담겨야 한다.
REST 원칙에 맞지 않음, 이는 POST 요청이므로 리소스 상태를 생성하지 않을 것이기 때문입니다.
REST 원칙에 따르면, 정상적으로 리소스가 생성되면 HTTP 상태 코드 201 (Created)를 반환하며, 생성된 리소스의 URL을 Location 헤더에 포함시켜야 한다. 이는 클라이언트가 생성된 리소스의 정보를 얻을 수 있도록 도와준다.

B. 정상 응답 코드는 201 Created 여야 한다.
REST 원칙에 맞지 않음, 정상적으로 처리된 경우 HTTP 응답 코드 200 OK를 사용하여야 합니다.
RESTful API의 원칙에 따라, 새로운 리소스가 정상적으로 생성되었을 때의 HTTP 응답 코드는 201 Created 여야 한다는 것을 나타냅니다. 

C. 오류 응답 코드는 503 Service Unavailable 여야 한다.
REST 원칙에 맞지 않음, 409 Conflict HTTP 응답 코드는 같은 리소스가 중복 생성되려 하는 경우에 사용되어야 합니다.
오류 응답 코드는 503 Service Unavailable 이 아닌 409 Conflict이어야 한다. 503 Service Unavailable은 서버에서 작업을 수행하지 못할 때, 예를 들어 점검 중이거나 다운된 경우에 사용하는 코드이고, 이 경우에는 서버가 작동하고 있지만 사용자 요청에 대한 응답으로 오류가 발생하므로 409 Conflict이 되어야 한다.

D. 응답 메시지는 영문으로 쓰여져야 한다.
REST 원칙에 맞지 않음, 응답 메시지의 언어는 구체적인 규칙이 없기 때문에 자유롭게 작성될 수 있습니다.
응답 메시지는 영문으로 쓰여져야 한다는 것이 원칙은 아니다. REST API는 국제 표준이므로 언어에 상관 없이 동작하도록 설계되어 있습니다. 응답 메시지는 사용자에게 가장 이해하기 쉬운 언어로 작성되며, 대부분의 경우 개발자에 맞춰 영문으로 작성되지만 한국어 등 다른 언어로도 작성할 수 있습니다.

---

문제8. 게시판에서 10번 게시물을 삭제하는 엔드포인트를 작성하려고 합니다. 가장 적절한 것을 고르세요.

A. GET /delete

B. GET /delete body: { "id": "10" }

C. DELETE /delete

D. DELETE /articles/10

A. GET /delete
GET 메서드는 정보를 조회하는 연산을 나타낸다. 따라서, 삭제 연산이라면 DELETE 메서드를 사용하는 것이 적절하다.

B. GET /delete body: { "id": "10" }
GET 메서드는 보안상의 이유로 body에 데이터를 담지 않는 것이 관례이다. 따라서, 삭제하고자 하는 게시물의 ID(10)를 URL에 포함시켜 전송하는 것이 적절하다.

C. DELETE /delete
엔드포인트가 정의되어 있지 않은 URL이다. 따라서, 게시물의 ID(10)가 들어가는 URL을 사용하는 것이 적절하다.

D. DELETE /articles/10
RESTful API는 URL을 통해 리소스에 대한 정보를 구분하므로, 게시물의 ID(10)가 들어가는 URL을 사용하는 것이 적절하다. DELETE HTTP 메서드는 리소스를 삭제하는 연산을 나타낸다.