Siesta 리소스에 대한 요청 방법 구성

Question

대부분의 다른 요청은 get으로 작동하는 동안 로그인을 통해이 api를 사용할 수 있습니다. 이제 siesta를 사용하여 로그인 URL을 리소스로 정의합니다.

func login(username: String, password: String) -> Resource { 
    return self.resource("login").withParam("username", username).withParam("password", password); 
} 

문제는 내가이 자원에() .loadIfNeeded를 사용할 때 GET 요청을 할 것입니다하지만 POST 요청을 할 필요가 있기 때문 작동하지 않습니다.

이제는 .decorateRequests의 존재를 알고 있지만,이를 사용하여 로그인 정보를 요청 방법으로 사용하는 방법을 확신 할 수 없습니다. 사전에

감사합니다,

피터

Answer 1

시에스타의 load() 및 loadIfNeeded()는 GET 요청 만입니다.

왜? 이러한 시에스타 방법은 부작용이없고, 결과를 캐싱 할 수 있으며, 0, 1 또는 여러 번 호출하는 것이 안전하다는 가정하에 작성됩니다. HTTP에서 이것은 GET 계약입니다. 그러나 POST, PUT 등은 그러한 약속을하지 않습니다. 각 요청은 별도의 효과를 가질 수 있으므로 반복적으로 또는 선택적으로 호출하는 것은 위험합니다.

는 POST가, PUT 사용하여 요청을하고, DELETE, Resource.request(…) 사용하려면 (. request(…)이 load(…) 어떻게 다른지에 대한 추가 정보를 원하시면 the section on requests in the Siesta user guide 참조)

loginResource.request(.post) 

---

왜 아니다 예를 들어, 자원을 "POST 자원"으로 만드는 별도의 설정이 있습니다. REST 접근 방식은 /foo이 논리적 인 것의 이름 인 자원과 GET /foo입니다 및 PUT /foo은 서로 다른 조치를 취합니다. 하나는 상태를 검색하고 다른 하나는이를 변경합니다. 이것은 단순히 심미적 인 순결의 문제가 아닙니다. GET의 강력한 약속은 그 약속과 밀접하게 연관되어 있습니다.

API가 완전히 REST 형태가 아닌 경우 Siesta가 적합하지 않을 수 있습니다. 그러나 REST 형식의 요청을 API 자체 구조로 변환하는 NetworkProvider을 작성하여 Siesta가 본질적으로이를 REST API로 처리하도록 할 수도 있습니다.

---

API는 일반적으로 (withParam(…)가하는 일입니다) 쿼리 문자열에 암호를하지 않는 것이 아니라 게시물 본문입니다.

(단, API가 검색어 문자열에서 비밀번호를 사용하는 경우에는 원치 않는 것일 수 있습니다. 검색어 문자열의 비밀번호는 안전하지 않은 장소 (예 : 로그 파일)로 누출되기 쉽습니다. , 그리고 나는 당신이 종종 가지고있는 것과 함께 일해야한다는 것을 깨닫습니다!당신의 API 대신 쿼리 문자열의 POST 본문에 암호를 가지고 간다 가능성이 이벤트에서)

, 당신은이 작업을 수행 할 수 있습니다

// If it’s a JSON request 
loginResource.request(.post, json: ["user": user, "password": pass]) 

// If it an HTML form encoded request 
loginResource.request(.post, urlEncoded: ["user": user, "password": pass]) 

---

당신이 정말 낮잠이 결과를 캐시하려면 당신의 인증 호출의 그것은 했다 된 GET 요청, 당신은 Resource.load(using:)를 사용할 수있는 것처럼 :

authResource.load(using: 
    authResource.request(
     .post, json: ["user": user, "password": pass])) 

이 유용 당신을 게시 할 경우 예를 들어 ResourceObserver을 사용하여 앱 내 자격 증명을 만들 수 있습니다. 더 일반적인 방법은 onSuccess 후크를 사용하여 자격 증명을 한 번 가져 와서 서비스 구성을 업데이트하는 것이지만 load(using:)은 상황에 따라 유용한 대안이 될 수 있습니다.