Вы правда думаете, что запрос такого вида, как тот что ниже, будет проще для использования в коде чем одна строчка с хорошо читаемым форматом?
Да, я специально немного утрировал пример, можно создать функции для get и post запросов с входными параметрами, можно сделать функции для каждого конкретного запроса и т.д., но чем больше вы будете пытаться сделать слой универсальным, гибким и простым в использовании, тем больше вы будете приближаться к чему-то похожему на эту статью. В больших проектах вызовы запросов встречаются в сотнях мест, и даже небольшое сокращение кода при работе с запросами и более понятный и читаемый синтаксис могут принести огромную пользу. Вносить изменения в такой слой тоже, наоборот, легче, вам надо например поменять стандартный хедер в get-запросах, тип кодировки или еще что-то подобное, вы его поменяете всего в одном месте, никаких проблем. И эти «украшательства» абсолютно ничем не ограничивают возможности, их никто не отнимал, добавляйте что хотите. И для новых разработчиков такой «фреймворк» не принесет никакого неудобства, наоборот, пользоваться им проще некуда, написать его непросто, а пользоваться им уж точно не сложно + такой подход защитит от самодеятельности этих самых новых разработчиков, в то время как дав им возможность реализовать запросы через URLSession в том виде в каком они хотят однозначно приведет к тому что каждый реализует как бог пошлет. Жить безусловно можно и с URLSession, но так — намного удобнее.
let config = URLSessionConfiguration.default
let session = URLSession(configuration: config)
let url = URL(string: "https://httpbin.org/anything")!
var urlRequest = URLRequest(url: url)
urlRequest.httpMethod = "POST"
// your post request data
let postDict : [String: Any] = ["name": "axel",
"favorite_animal": "fox"]
guard let postData = try? JSONSerialization.data(withJSONObject: postDict, options: []) else {
return
}
urlRequest.httpBody = postData
let task = session.dataTask(with: urlRequest) { data, response, error in
// ensure there is no error for this HTTP response
guard error == nil else {
print ("error: \(error!)")
return
}
// ensure there is data returned from this HTTP response
guard let content = data else {
print("No data")
return
}
// serialise the data / NSData object into Dictionary [String : Any]
guard let json = (try? JSONSerialization.jsonObject(with: content, options: JSONSerialization.ReadingOptions.mutableContainers)) as? [String: Any] else {
print("Not containing JSON")
return
}
print("gotten json response dictionary is \n \(json)")
// update UI using the response here
}
// execute the HTTP request
task.resume()
Codable безусловно не панацея, и можно использовать сторонние библиотеки, к сожалению AlamofireObjectMapper не использовал, пробовал только SwiftyJSON, но в итоге больше понравился Decodable и у меня весь проект сделан на нем, более 50 APIшек со структурами данных разной сложности, без проблем. Но, зная Alamofire, думаю у них тоже достойный продукт.
Сложно понять, что вы хотите добиться, если вам нужен JSON, то вы его получите после сетевого запроса и можете делать с ним что хотите, можете оставить так и хранить, например, если же вам нужны данные из JSON, то Decodable распарсит.
Зачем использовать дополнительный parser, если Codable автоматически сам распарсит все поля? Если надо добавить еще поля в модель, то это делается одной строкой, добавляете поле и все, не вижу никаких проблем. Codable для того и существует, чтобы не писать лишний код
и проект на гитхабе: github.com/bwhiteley/JSONShootout
Да, я специально немного утрировал пример, можно создать функции для get и post запросов с входными параметрами, можно сделать функции для каждого конкретного запроса и т.д., но чем больше вы будете пытаться сделать слой универсальным, гибким и простым в использовании, тем больше вы будете приближаться к чему-то похожему на эту статью. В больших проектах вызовы запросов встречаются в сотнях мест, и даже небольшое сокращение кода при работе с запросами и более понятный и читаемый синтаксис могут принести огромную пользу. Вносить изменения в такой слой тоже, наоборот, легче, вам надо например поменять стандартный хедер в get-запросах, тип кодировки или еще что-то подобное, вы его поменяете всего в одном месте, никаких проблем. И эти «украшательства» абсолютно ничем не ограничивают возможности, их никто не отнимал, добавляйте что хотите. И для новых разработчиков такой «фреймворк» не принесет никакого неудобства, наоборот, пользоваться им проще некуда, написать его непросто, а пользоваться им уж точно не сложно + такой подход защитит от самодеятельности этих самых новых разработчиков, в то время как дав им возможность реализовать запросы через URLSession в том виде в каком они хотят однозначно приведет к тому что каждый реализует как бог пошлет. Жить безусловно можно и с URLSession, но так — намного удобнее.