유감스럽게도 Connection에는 이미 options 접근자가 있으므로 OPTIONS 요청을 만들기 위해 이를 용도 변경할 수 없습니다. run_request(:options) 를 사용해야 합니다.

아마도 순진한 가정이지만 다른 사용 패턴을 갖는 것보다 :options 를 :configuration 에 다시 매핑하는 것이 더 쉽지 않을까요?

거의 사용되지 않는 HTTP를 지원하도록 설정된 API를 변경하고 싶지 않습니다.
run_request 통해 쉽게 액세스할 수 있는 메서드입니다.

IMHO, 이 결정을 재고해야 합니다. OPTIONS 는 유효한 HTTP 메서드 이름이고 run_request 가 항상 적합한 대안은 아닙니다. 공개 API를 중단하려면 나중에 결정을 후회하는 것보다 1.0을 출시하기 전에 지금 하는 것이 좋습니다.

run_request 가 항상 적절한 대안이 아닌 이유는 무엇입니까?

Faraday를 기반으로 구축하는 하위 수준의 라이브러리 작성자의 경우
실제로 run_request 보다 get , post 방법을 사용하는 것이 좋습니다.

@mislav #run_request 는 #get , #post 등과 같이 블록을 사용하지 않습니다. Twitter::REST::Client#request 에서 Faraday를 사용하는 방법을 살펴보세요. https://github.com/sferik/twitter/blob/master/lib/twitter/rest/client.rb#L130 -L144

run_request는 #get, #post 등과 같은 블록을 사용하지 않습니다.

그렇게 생각하는 이유는 무엇입니까 ?

귀하의 사용 사례는 run_request 를 사용하는 완벽한 예입니다. 즉, send 를 피하는 것입니다.

이제 내가 #run_request 좋아하지 않는 이유를 기억합니다. 실제로 Twitter::Client#request 코드의 한 지점에서 사용했지만 리팩토링의 일부로 제거했습니다: https://github.com/sferik/twitter/commit/2d70b64674bdc204c85c47327afa571f9641e545. #send 코드가 훨씬 깔끔하다는 점을 인정해야 한다고 생각합니다(그렇지 않기를 바랍니다).

#run_request 하면 요청이 PUT 인지 POST 인지 걱정하고 GET , DELETE 대한 요청 본문 대 쿼리 매개변수를 설정해야 했습니다 #run_request 보다 훨씬 친숙한 인터페이스입니다.

#send 를 #run_request 바꾸는 twitter gem에 pull 요청을 제출하여 덜 복잡한 코드를 생성하도록 요청합니다(Code Climate 또는 기타 정적 분석에 따르면 ).

OPTIONS 방법을 방어하기 위해 HTTP 동사의 미래 인기를 추측하는 것은 매우 어렵습니다. HTTP 1.0에서는 GET과 POST만 있었습니다. 1999년에 HTTP 1.1에 더 많은 동사가 추가되었지만 Rails 2가 리소스 경로에서 PUT 및 DELETE 에 대한 지원을 추가할 때까지 대부분 무시되었습니다. 이제 Rails 4에서 PATCH 가 PUT 와 함께 지원됩니다. 몇 년 전에 " PATCH 는 인기가 없다"고 (올바르게) 주장했을 수 있으며 따라서 일류 지원이 필요하지 않습니다. 오늘날 Rails로 작성된 모든 새로운 API 서버는 GitHub API를 포함하여 PATCH 를 지원하며, Rails 4가 출시되기 전에 PATCH 를 지원했습니다. GitHub API는 CORS(Cross Origin Resource Sharing)에 대해 OPTIONS 도 지원합니다. OPTIONS 은 아직 대중적이지 않을 수 있지만, CORS가 Rails 5에서 기본값으로 추가된다면 거의 하룻밤 사이에 대중화될 것입니다. 이런 일이 발생하면 이 문제를 무시하고 후회하게 될 것입니다.

HTTP 동사는 HTTP 라이브러리에 대한 중요한 예약어입니다. 그들 중 소수만이 있고 내 생각에 우리는 패러데이 1.0에서 일류 시민으로서 그들을 모두 지원해야 합니다. 비록 그것이 길을 가로막는 것을 의미하더라도 말입니다.

CORS는 매우 중요한 사용 사례입니다. 1.0이 일급 동사로 OPTIONS 없이 배송된다면 실망할 것입니다.

이런 _bump_에 대해 대단히 유감입니다. 하지만 OPTIONS 요청에 대한 방법으로 options 를 지원하는 데 동의하십니까? 이를 실현하기 위해 풀 리퀘스트를 제출하게 되어 기쁩니다.

나는 아직도 그 아이디어에 대해 팔리지 않았다. 그러면 현재의 options 메서드는 무엇을 호출할까요?

우리가 지원하는 다른 방법은 동사입니다: get, post, put, delete. 당신이 그들을 부를 때 어떤 행동이 일어나고 있다는 것을 쉽게 이해할 수 있습니다. options 는 동사가 아니므로 좋은 속기 방법이 될 것이라고 생각하지 않습니다. 사람들이 일상적인 코드에서 톤당 OPTIONS 를 사용하고 있고 어떤 이유로 run_request 를 사용하는 것을 견딜 수 없다면(그 이유를 듣고 싶습니다!) 다음을 제안합니다. 새 메서드의 이름을 http_options 로 지정하여 이것이 HTTP 요청 메서드임을 나타냅니다.

"다른 방법은 동사다"라는 주장은 중요하지 않습니다. 그것들은 동사이기 때문에 패러데이의 메소드가 아니며, 그 메소드는 HTTP 메소드이기 때문에 존재합니다. options IMO에서도 마찬가지입니다.

이것이 options 없는 이유라면 HTTP의 "head"는 동사인 "going"이 아니기 때문에 head 를 정의해서는 안 됩니다.

options API를 깨는 것에 대한 우려를 완전히 이해하지만 "지원"되지 않는다는 것은 큰 놀라움입니다. 모든 HTTP 메소드가 동일하게 처리되도록 하는 것이 훨씬 더 일관성이 있습니다.

그리고 run_request 사용하지 않는 것에 대해서는 앞에서 지적한 것처럼 이 코드가 없는 코드가 훨씬 깨끗합니다.

이것을 지원하기로 결정하는 것은 여전히 ​​당신의 부름(분명 :-) 이지만, 나는 그것에 대해 당신의 마음을 바꾸고 싶습니다. 그리고 그것이 지원되지 않을 것이라면 그것은 "_options_가 아닌 다른 것을 위한 것입니다. 동사".

+1 @nhoki

이것은 오늘 나를 놀라게 했다. conn.get , conn.post , conn.delete 등의 모든 예제는 OPTIONS 요청을 수행하는 확실한 방법이 conn.options 라고 믿게 만듭니다.

Faraday::Connection rdocs 또는 README?에서 이 불일치와 run_request 해결 방법을 문서화할 수 있습니다. 풀 리퀘스트를 작성하게 되어 기쁩니다.

+1

옵션이 GET, POST, DELETE와 동일하지 않은 이유는 무엇입니까?

개인적으로 @mislav 에 동의하지만 @sferik 의견과 커뮤니티 피드백을 무시할 수 없습니다. 코드를 확인하고 options 는 단순히 attr_reader 이며 주로 테스트에서 사용되는 것으로 나타났습니다.
그러나 변경 중인 일부 구현을 잠재적으로 중단할 수 있는 공개 API에 대해 이야기하고 있으므로 이 문제는 Faraday 1.0에서만 해결됩니다.
그때까지 반대하는 사람이 있으면 다시 논의하게 되어 기쁩니다.

conn.options 은(는) 완전히 가치가 있어야 한다고 생각합니다. conn.get , conn.post 등의 존재로 인해 그 존재가 크게 나타납니다. 그러나 이전 버전과의 호환성을 깨뜨릴 것이기 때문에 v1.0은 이것을 적용하기에 좋은 대상처럼 들립니다.

좋은 소식입니다. 기존 동작을 유지하면서 새로운 동작을 지원하기 위해 #options 를 오버로드하여 이것을 구현했습니다. https://github.com/lostisland/faraday/pull/857