ServiceV Pro: Default response unexpectedly replacing the scripted one

[MeT]

First thing first: I'm new to the ServiceV product, just got it few days ago.

I'm creating a virt api where the following path is being used:

/api/aicm/v1/subject/{subject_nr}/mandate/{creditor_id}

where subject_nr and creditor_id represent the required TEMPLATE parameters.

Beside the main success scenario (GET: -> HTTP 200 OK), where both arguments are made available in the URI, I'm trying to handle the following alternative scenarios in my virt api:

a) GET: {subject_nr} is empty -> HTTP 400 Bad Request
b) GET: {creditor_id} is empty -> HTTP 400 Bad Request
c) GET: both {subject_nr} and {creditor_id} are empty -> HTTP 400 Bad Request

The test paths associated with the four scenarios (1 main + 3 alts) are:

1. HTTP 200: /urds/wrd/api/aicm/v1/subject/0303200001/mandate/AB51TST405365330000
2. HTTP 400: /urds/wrd/api/aicm/v1/subject//mandate/AB51TST405365330000
3. HTTP 400: /urds/wrd/api/aicm/v1/subject/0303200001/mandate/
4. HTTP 400: /urds/wrd/api/aicm/v1/subject//mandate/

 I use the "Dispatch Strategy: Script" with default response returning HTTP 404 Not Found, and the following validation script to check the path arguments and return the appropriate response:

assert log
log.info("Executing dispatch script...")

assert requestContext
def props = requestContext.getProperties()
assert props
log.info("Request arguments: ${props}")

def subNr = props["subject_nr"]
def credId = props["creditor_id"]

if (subNr.empty || credId.empty) {
	// return HTTP 400
	return "GET 400 Bad Request"
}

log.info("subject_nr: ${subNr}")
log.info("creditor_id: ${credId}")

def isSubNrMatching = subNr ==~ /^\d{10}$/
log.info("subject_nr RegEx match is: ${isSubNrMatching}")
def isCredIdMatching = credId ==~ /^(ab|AB)(\d{2})([a-zA-Z]{3})(\d{8})(0{4})$/
log.info("creditor_id RegEx match is: ${isCredIdMatching}")
def areReqArgsValidated = isSubNrMatching && isCredIdMatching

if (!areReqArgsValidated) {
	// return HTTP 400
	return "GET 400 Bad Request"
}

log.info("Request arguments validated: ${areReqArgsValidated}")

// return HTTP 200
return "GET 200 OK"

Now, the problem is:

Main success scenario and alternative scenario a) work just fine (meaning: in both cases I get the expected response dispatched by the script).

With the remaining scenarios b) and c), a response with HTTP status code 404 is dispatched instead of the scripted one (400). This response is apparently not the default 404 response I created and selected in the "Default Response" drop-down list (which features a JSON payload in the body), for its body is empty.

Additionally, no log output shows up in the script (or error) log tab, showing clearly that the dispatch strategy script is not executed.

Any clue about why is this happening? Am I missing something fundamental, due to my lack of product knowledge?

[AlexKaras]

@MeT:

Hi,

Thank you a lot for the update. I did not try it yet, but certainly will do. 🙂

Initially, your solution seemed to me to be a kind of workaround and I was going to suggest to create either an issue or feature request.

However, after some consideration, I am already less confident and tend to consider your solution as a valid and correct approach. I did not check what standard says about duplicated slashes within and at the end of address, but from what I remember, browsers usually ignore duplicated slashes and navigate to the same resource.

For example, https://support.smartbear.com////versions/// navigates to the same page as https://support.smartbear.com/versions/ and https://support.smartbear.com/versions.

So, even though your given virt contains template parameter at the end of the path, it looks reasonable that if this final parameter is missed, then the path still looks like a valid REST path (for example, like a request to get IDs of all creditors for the given subject) and ServiceV has no good reason to consider that this is a request with the missed last parameter. And thus it returns default internal 404 because no virt was specified for the requested resource.

This is my current understanding and explanation. Do you think I missed something ?

@Olga_T:
Olga, is it possible to ask your technical writers to extend the documentation section for Template parameters with the description of ServiceV behavior when the final parameter in the path is missed and what actions must be done in this case, based on the approach by @MeT? Thank you.

[Olga_T]

@AlexKaras,
Sure, I have assigned a new task to our Documentation team in our internal system based on your request.

[MeT]

@AlexKaras

Hi Alex,

I believe your understanding as described in your post is correct.

From my side, I just want to add some additional details, which my conclusions are based upon.

If you test the following URLs in Chrome or Firefox, you'll be seeing the following behaviour in their address bar:

1. https://www.google.nl    =>    https://www.google.nl
2. https://www.google.nl/   =>    https://www.google.nl    <<< Forward slash is stripped out
3. https://www.google.nl//  =>    https://www.google.nl//  <<< Forward slashes are not stripped out

The reason of this behaviour is that a double forward slash represents a path segment, and apparently it doesn't matter if its value is an empty string or not, as long as the part of the URL preceeding it is a valid URI.

The test paths I have provided in my previous posts have been designed with this consideration in mind. For all those paths where the second argument is missing, it's up to us to provide suitable fallback resources, in order to be able to handle them correctly and eventually dispatch a custom response.

Please let me know if this helps clarifying the matter even further. 

[AlexKaras]

Hi,

Back from my vacation and returned to scenario by @MeT as it is still pretty good for my self-education 🙂

I did not check whether or not it is specified in RFCs, but from the end-user tester's point of view I tend now to consider the approach marked as solution to be a workaround instead.

As I see it now, virt developer (i.e. tester) must provide at least those requests for the virt:

-- /subject/{subject_nr}/mandate/{creditor_id} -- main scenario;

-- /subject/mandate/{creditor_id} -- for missed {subject_nr} parameter with removed '/' in the path;

-- /subject/{subject_nr}/mandate/ -- for missed {creditor_id} parameter;

-- /subject/mandate/ -- for both parameters missed

Besides that, tester must carefully think what request to call from ServiceV while verifying this or that combination of parameters. And this is, obviously, pretty inconvenient.

It seems to me at the moment, that it would be more convenient if (for requests declared as those with parameters in the path) ServiceV consider the possibility of some parameter to be empty and ignored the number of the subsequent slashes in case the parameter is missed.

E.g. :

/subject/123/mandate/aaa

/subject//mandate/aaa

/subject/mandate/aaa

/subject/mandate/

/subject//mandate//

all should be dispatched to the same

/subject/{subject_nr}/mandate/{creditor_id}

template request and then it must be tester's responsibility (via dispatching script) to handle missed parameters as required.

@Olga_T, @TanyaYatskovska: Ladies, could you please ask architects'/developers' opinion about this case and, unless it contradicts some RFC section, let us know whether we may report this as an issue or feature request.

[MeT]

@AlexKaras

Hi and welcome back, hope you enjoyed your vacation! 

I'd like to ask you to think for a moment to the semantics of the following paths:

1. /subject/{subject_nr}/mandate/{creditor_id}   >>> path featuring 2 template params: when filled in, it validly represents a possible URI
2. /subject//mandate/{creditor_id}   >>> path featuring 2 template params, where the 1st one is missing, it does NOT validly represent a possible URI
3. /subject/mandate/{creditor_id}   >>> path featuring 1 template param: when filled in, it validly represents a possible URI
4. /subject/mandate//   >>> path featuring 1 missing template param: it might validly represent a possible URI only if you drop the last forward slash
5. /subject/mandate/   >>> path featuring 0 template params: it validly represents a possible URI
6. /subject/mandate   >>> path featuring 0 template params: it validly represents a possible URI

Consequently, in case of paths 4, 5 and 6, it's reasonable to expect a status code 404 Not found, if you didn't take care of implementing support for path 6 in your service.

Hope this helps! 

[Olga_T]

Hi all,

@AlexKaras, sure, I have contacted one of our engineers regarding the query. They should look into it shortly.

I will get back to you as soon as I have any updates.

[Olga_T]

Hi all,

I've got some updates from the developers. It looks like the investigation can take long, so the best way to proceed here is to create a support ticket. 

@MeT, it would be great if you could later share your results with us here 

Thanks in advance!