알 수없는 매개 변수를 허용해야합니까?

RESTful API를 디자인하고 제목 문제에 직면하여 명확성을 위해 다시 작성되었습니다.

클라이언트가 인식 할 수없는 매개 변수를 보내면 빨리 실패해야합니까? 예를 들어

http://example.com/api/foo?bar=true&paula=bean

위의 bar매개 변수는 유효한 매개 변수이지만 paulaAPI에서 지정하지 않았습니다. 내가해야합니까

클라이언트에게 오류 경고
빨리 실패
무시해

클라이언트에 경고하면 거의 무한한 수의 매개 변수를 보낼 수 있고 서버에 더 나은 작업이 있기 때문에 첫 번째 매개 변수에 대해서만 경고를 발행 할 수 있습니다. 마찬가지로 실패하면 첫 번째 잘못된 매개 변수 만 문제로 지정합니다.

나는 프로그래머가 문제를 무시하고 자원을 낭비하거나 실수로화물을기를 수 있기 때문에 조치를 취하라는 경고를 발행하지 않는 것을 선호합니다. 그 점에서 아무것도하지 않는 것이 더 나쁩니다.

내 주장이 이해가 되나요? 그런 것들에 대해 받아 들여지는 관행이 있습니까?

rest api-design

— 아침 일찍
소스

작은 테스트를 기반으로 테스트 한 모든 사이트는 내가 제공 한 알 수없는 매개 변수를 무시합니다.

— Bart van Ingen Schenau

@BartvanIngenSchenau 여기 동일합니다. 웹 페이지에는 문제가 없지만 실제 API에는 문제가 없다고 생각합니다

— rath

문제는 순방향 호환성입니다. 알 수없는 인수가 무시되면 클라이언트가 새 API에 프로그래밍하고 이전 서버에서 여전히 합리적인 동작을 얻을 수있는 방식으로 이후 버전에서 사용할 수 있습니다.

— walpen

@walpen 흥미로운 점입니다. 버전이 지정된 URL api/v1등을 사용하면 이를 처리 할 수 있지만 여전히 증분 업데이트를 허용하지 않습니다. 한

— 라스

실제 라이브 관점에서 볼 때 몇 가지 장단점을 찾을 수 있습니다 : 엄격한 매개 변수 및 API .

— Remek Ambroziak

답변:

내 의견으로는, 유효하지 않은 요청 상태를 반환해야 클라이언트가 수행하려는 작업이 유효하지 않다는 것을 클라이언트가 알 수 있습니다. 이것에 대한 나의 의견은 RESTful API가 발견 가능 하다는 개념에 영향을 받는다 . 충분한 정보를 미리 제공하는 경우 클라이언트는 잘못된 요청을 시작하려고 시도하지 않습니다. 그렇다면 클라이언트 코드에 문제가 있으며 빠르게 실패하면 두 번째 버그에 경고합니다. 물론 이는 매우 순수한 접근법이며 API를 찾을 수없는 경우에는 권장되지 않을 수 있습니다.

더 실용적인 접근 방식은 잘못된 매개 변수를 무시하는 것이지만 어느 쪽을 가든 행동을 잘 문서화해야합니다.

— 러버 덕
소스

확장으로서 : 클라이언트가 알려지지 않은 / 읽기 전용 / 더 이상 사용되지 않는 매개 변수를 보내면 클라이언트는 충족되지 않는 일부 동작을 예상합니다. 따라서 어떤 조치를 수행하는 것은 위험합니다. 그래서 나는 엄격히 나쁜 요청에 동의합니다

— Stepan Stepanov

@StepanStepanov에게 감사드립니다. 그러나 웹 아키텍처의 근간을 이루는 "수용하는 것에 허용하고, 발송하는 것에 대해 명시 적"이라는 철학이 있습니다. 그 점을 염두에두고, 나는 이미 쓴 것에 반대되는 대답을 쉽게 쓸 수있었습니다.

— RubberDuck

나는 이것을 봤다)) 그리고 Postel의 법칙에 관한 페이지는 "입력을받는 코드가 의미가 명확한 한 부적합한 입력을 받아 들여야한다"고 말한다. 클라이언트가 알려지지 않은 매개 변수를 보내면 의미가 명확하지 않다고 생각합니다. 클라이언트가 더 이상 사용되지 않는 매개 변수를 보내면 이전과 같이 작동하지 않으며 클라이언트가 예상 한대로 작동하지 않습니다. 클라이언트가 읽기 전용 매개 변수를 보내면 클라이언트가 원하는대로 작성되지 않습니다.

— 스테판 스테파노 프

공개 API (또는 다른 팀에서 사용할 API)를 수행하는 경우 @RubberDuck이 제안한대로 반환 오류를 권장합니다.

API가 팀 내에서만 (또는 혼자서만) 소비되는 경우 추가 필드를 무시하는 것이 더 쉽습니다 (예 : 코드가 덜 필요하고 수행하기 쉬움).

— 콘스탄틴 페 트루 노프
소스