Open cryptoman256 opened 5 years ago
That's correct, the query parameters are stripped when the router is registered in the HTTPRouter
. But you could always create a mechanism to handle it and return responses regarding the query parameter if it's what you need. #285 show a simple example of how you can do it.
@Vkt0r is there any plan to support this? So mock server always honour the parameters if they are in? If not what is the rationale of not having?
@CoderXpert I think this is something we can bring to the library and would be very useful for a lot of people. Sorry, I cannot provide with an ETA at this point but I hope we can update it at some point very soon.
If not what is the rationale of not having?
Honestly, I don't know exactly what was the reason for not having it initially.
I'll try to make an investigation about how much effort would take to add to the library. Let's hope not too much 😅. Sorry for not being more helpful at this point.
@Vkt0r Yeah that will be very helpful and thanks for picking this up for investigation. Please keep us updated as well :)
Here is an example i have done for using graphql and can be extended to query parameters as well. Simply match the body request or query parameters to the strings in the actual query params
//
// MockSwifterServer.swift
// ecobeeUITests
//
// Created by Rishi Khan on 2019-02-05.
//
import Foundation
import Swifter
enum HTTPMethod {
case POST
case GET
case PUT
}
struct HTTPStubInfo {
let url: String
let jsonFilename: String
let method: HTTPMethod
}
let initialStubs = [
HTTPStubInfo(url: "/1/user", jsonFilename: "user", method: .GET),
HTTPStubInfo(url: "/authorize", jsonFilename: "authorize", method: .POST),
HTTPStubInfo(url: "/graphql", jsonFilename: "", method: .POST)
]
struct graphQuery {
let queryName: String
let jsonResponseFile: String
}
let graphDict = [
graphQuery(queryName: "RootModelHomeSettings",jsonResponseFile: "RootModelHomeSettings"),
]
class MockServer {
var server = HttpServer()
func setUp() {
try! server.start(port)
setupInitialStubs()
}
func tearDown() {
server.stop()
}
func setupInitialStubs() {
for stub in initialStubs {
setupStub(url: stub.url, filename: stub.jsonFilename, method: stub.method)
}
}
public func setupStub(url: String, filename: String, method: HTTPMethod) {
var jfilename: String?
let response: ((HttpRequest) -> HttpResponse) = { request in
if !(request.body.isEmpty) && request.queryParams.isEmpty{
let req_body = String(bytes: request.body, encoding: .utf8)
for query in graphDict{
if (req_body?.contains(query.queryName))!{
jfilename = query.jsonResponseFile
break
}
}
}
else {
jfilename = filename
}
let testBundle = Bundle(for: type(of: self))
let filePath = testBundle.path(forResource: jfilename, ofType: "json")
let fileUrl = URL(fileURLWithPath: filePath!)
let data = try! Data(contentsOf: fileUrl, options: .uncached)
let json = self.dataToJSON(data: data)
return HttpResponse.ok(.json(json as AnyObject))
}
switch method {
case .GET :
server.GET[url] = response
case .POST:
server.POST[url] = response
case .PUT:
server.PUT[url] = response
}
}
func dataToJSON(data: Data) -> Any? {
do {
return try JSONSerialization.jsonObject(with: data, options: .mutableContainers)
} catch let myJSONError {
print(myJSONError)
}
return nil
}
// MARK: Private
let port: UInt16 = 2300
}
//
@Vkt0r I have a question related to this thread. Is it possible to have the same URL return different stubs based on the query's body parameter?
I have the same url that I expect to return two different JSON files based on what is passed into the body query. I tried to do something similar to the suggestions in this thread, but it seems like the second url overrides the first when I setup both.
@andynovak12 I'm seeing that in #285 you have an answer for it. Let me know if you need more help with that but the solution provided is an easy way to prepare the stub based in the URL
, method, etc
If I may add, one tricky aspect of matching against query parameters directly on the router is that they may not be in the order you'd expect. /foo?lang=en&device=ios
is essentially equivalent to /foo?device=ios&lang=en
. It also raises the question of, should /foo?lang=en
match /foo?bar=baz&lang=en
?
From what I see in other web frameworks, query string may not necessarily be part of the router matching, but perhaps there is utility in implementing a generic "filtering" plugin that might match headers, query parameters, or whatever. The benefit of this approach is to keep path matching speedy and simple, while allowing users to extend the matching functionality explicitly at their own discretion.
The library is parsing the query params but then not using them to match.
Problem is:
http://example.com/search/location?city=chi
is the same ashttp://example.com/search/location?city=nyc
to swifter