[ios] Alamofire의 URLRequestConvertible의 적절한 사용

좋은 질문입니다. 각각을 개별적으로 분석합시다.

실제 API에서 URLRequestConvertible의 올바른 사용법은 무엇입니까?

URLRequestConvertible프로토콜은 유효을 만들 수 지정된 객체를 보장하는 경량의 방법입니다 NSURLRequest. 이 프로토콜을 특정 방식으로 사용하도록 강요하는 엄격한 규칙이나 지침은 없습니다. 다른 개체가 NSURLRequest. Alamofire와 관련된 더 많은 정보는 여기 에서 찾을 수 있습니다 .

엔드 포인트 당 하나의 라우터를 만들어야합니까?

절대 아니다. 그것은 Enum. Swift Enum 객체는 놀랍도록 강력하여 많은 양의 공통 상태를 공유하고 실제로 다른 부분을 켤 수 있습니다. NSURLRequest다음과 같이 간단한 것을 만들 수 있다는 것은 정말 강력합니다!

let URLRequest: NSURLRequest = Router.ReadUser("cnoon")

라우터 구축에 enum이 사용되는 이유를 알 수 없습니까? 정적 메서드에 클래스를 사용하지 않는 이유는 무엇입니까?

열거 형은 공통 인터페이스에서 여러 관련 객체를 훨씬 더 간결하게 표현하기 때문에 사용됩니다. 모든 방법은 모든 케이스간에 공유됩니다. 정적 메서드를 사용한 경우 각 메서드에 대한 각 경우에 대한 정적 메서드가 있어야합니다. 또는 개체 내부에 Obj-C 스타일 열거 형을 사용해야합니다. 여기 제가 의미하는 바에 대한 간단한 예가 있습니다.

enum Router: URLRequestConvertible {
    static let baseURLString = "http://example.com"

    case CreateUser([String: AnyObject])
    case ReadUser(String)
    case UpdateUser(String, [String: AnyObject])
    case DestroyUser(String)

    var method: Alamofire.HTTPMethod {
        switch self {
        case .CreateUser:
            return .post
        case .ReadUser:
            return .get
        case .UpdateUser:
            return .put
        case .DestroyUser:
            return .delete
        }
    }

    var path: String {
        switch self {
        case .CreateUser:
            return "/users"
        case .ReadUser(let username):
            return "/users/\(username)"
        case .UpdateUser(let username, _):
            return "/users/\(username)"
        case .DestroyUser(let username):
            return "/users/\(username)"
        }
    }
}

다른 끝점의 메서드를 가져 오려면 매개 변수를 전달하지 않고도 동일한 메서드를 호출하여 찾고있는 끝점 유형을 정의 할 수 있습니다. 선택한 경우에 이미 처리되어 있습니다.

let createUserMethod = Router.CreateUser.method
let updateUserMethod = Router.UpdateUser.method

또는 경로를 얻으려면 동일한 유형의 호출.

let updateUserPath = Router.UpdateUser.path
let destroyUserPath = Router.DestroyUser.path

이제 정적 메서드를 사용하여 동일한 접근 방식을 시도해 보겠습니다.

struct Router: URLRequestConvertible {
    static let baseURLString = "http://example.com"

    static var method: Method {
        // how do I pick which endpoint?
    }

    static func methodForEndpoint(endpoint: String) -> Method {
        // but then I have to pass in the endpoint each time
        // what if I use the wrong key?
        // possible solution...use an Obj-C style enum without functions?
        // best solution, merge both concepts and bingo, Swift enums emerge
    }

    static var path: String {
        // bummer...I have the same problem in this method too.
    }

    static func pathForEndpoint(endpoint: String) -> String {
        // I guess I could pass the endpoint key again?
    }

    static var pathForCreateUser: String {
        // I've got it, let's just create individual properties for each type
        return "/create/user/path"
    }

    static var pathForUpdateUser: String {
        // this is going to get really repetitive for each case for each method
        return "/update/user/path"
    }

    // This approach gets sloppy pretty quickly
}

참고 : 케이스를 전환하는 속성이나 함수가 많지 않은 경우 열거 형은 구조체에 비해 많은 이점을 제공하지 않습니다. 다른 구문 설탕을 사용하는 대체 접근 방식입니다.

열거 형은 상태 및 코드 재사용을 극대화 할 수 있습니다. 관련 값을 사용하면 다소 유사하지만 NSURLRequest생성 과 같이 매우 다른 요구 사항이있는 개체를 그룹화하는 것과 같은 매우 강력한 작업을 수행 할 수도 있습니다 .

가독성을 높이기 위해 열거 형 케이스의 매개 변수를 구성하는 올바른 방법은 무엇입니까? (이걸 함께 으깨 야 했어)

대단한 질문입니다. 이미 두 가지 가능한 옵션을 마련했습니다. 귀하의 필요에 더 잘 맞는 1/3을 추가하겠습니다.

case CreateUser(username: String, firstName: String, lastName: String, email: String)
case ReadUser(username: String)
case UpdateUser(username: String, firstName: String, lastName: String, email: String)
case DestroyUser(username: String)

연관된 값이있는 경우 튜플의 모든 값에 대해 명시적인 이름을 추가하는 것이 도움이 될 수 있다고 생각합니다. 이것은 맥락을 구축하는 데 정말 도움이됩니다. 단점은 다음과 같이 switch 문에서 해당 값을 다시 선언해야한다는 것입니다.

static var method: String {
    switch self {
    case let CreateUser(username: username, firstName: firstName, lastName: lastName, email: email):
        return "POST"
    default:
        return "GET"
    }
}

이것은 멋지고 일관된 컨텍스트를 제공하지만 꽤 장황합니다. 그것들은 현재 Swift에서 세 가지 옵션이며 사용 사례에 따라 올바른 옵션이 사용됩니다.

---

최신 정보

?? Alamofire 4.0 ??의 출시와 함께, URLRequestConvertible이제 훨씬 더 똑똑해지고 던질 수도 있습니다. 유효하지 않은 요청을 처리하고 응답 핸들러를 통해 현명한 오류를 생성하기 위해 Alamofire에 완전한 지원을 추가했습니다. 이 새로운 시스템은 README 에 자세히 설명되어 있습니다.