Choose API mock testing solution

[bajiat]

Definition of done

• Create functionality to check API type and how input parameters are accepted.
• Form to provide the input parameters.
• Button to try it out.

[as33ms]

IMHO, #331 and #76 are related, just that #331 is a smaller version of #76.

[as33ms]

While using the swagger ui, it already has a way to mock the APIs (using the Send Request OR Try it out functionalities). It alerts the user about Cross Origin Reference; so, the dashboard should be white-listed in the umbrella for access.

[bajiat]

@ashakunt Could you take this task?

[as33ms]

Mocking can be done in two ways:

1. Dummy data = where we just validate the input and return some dummy data to developer that "Hey, it should work"
2. Real Data = where we create a REAL "Try it out" request and then return the REAL status to the user.

While mocking the GET apis is easy in both the modes, mocking of PUT/DELETE APIs is going to be tricky because in CASE 2, we are actually going to delete the data.

[as33ms]

Based on discussions with @ccsr, @JuusoV and @ashakunt, we decided to use REAL DATA for mocking. So, native swagger implementation should already support the mocking by the "Try it out" or "Send Request" button. We just need to put the CORS (Cross Origin Resource Sharing) policies in place between API Umbrella and Dashboard.

One nice way to do this would be (for example in PHP):

 84 function enableCORS() {
 85     // Allow from any origin
 86     if (isset($_SERVER['HTTP_ORIGIN'])) {
 87         header("Access-Control-Allow-Origin: {$_SERVER['HTTP_ORIGIN']}");
 88         header("Access-Control-Allow-Methods: GET, POST");
 89         header("Access-Control-Allow-Headers: X-Requested-With");
 90     } else {
 91         error_log("CORS WAS NOT ENABLED (script: {$_SERVER['PHP_SELF']}, requested by: {$_SERVER['REMOTE_ADDR']})");
 92     }
 93 }

Of course, this means that all the requests from Dashboard should have HTTP_ORIGIN set to its own ORIGIN. Alternatively, one could also create a whitelist of HTTP_ORIGIN which have access to the Umbrella.

[as33ms]

Next crucial items are: When the API has WRITE methods like POST, PUT, DELETE, then a user should be alerted before mocking that "this is going to actually change the data on the server". Although, I am not sure, if that is required for MVP (cc: @bajiat )

[as33ms]

Swagger UI already has an authentication/access control mechanism in-built. There are multiple authentication mechanisms in place, like oauth2, plain http, ftp etc. This can be found by clicking on the slider under the header in the right corner (under the description of the method). We need to figure out how exactly to configure OAuth2 or if at all that is required?

[as33ms]

Did we already have CORS enabled? It would be good to cross check that Swagger's internal mocking actually works.

[brylie]

@JuusoV can we please have a status update here, based on your recent work/discussions?

[brylie]

@ashakunt, please follow up on the following CORS related issues in the API Umbrella tracker:

• Cross-Origin Resource Sharing (CORS) support
• CORS error when making requests through API umbrella

[bajiat]

@ashakunt, can you give a status update on this task?

[as33ms]

@bajiat I need to check a few things and I will provide an update by EOD today.

[as33ms]

I have tested the latest HEAD for mocking of API from the existing documentation (example JSON). It seems to work just fine.

[as33ms]

All the above items are already a part of swagger-ui. Current installed version of api-umbrella is 0.8.0-1 and as per NREL/api-umbrella-gatekeeper@9c275d7, it is a part of https://github.com/NREL/api-umbrella-gatekeeper/releases/tag/v0.8.16 .

Hence, after the update is applied to umbrella, this should be solved.

[as33ms]

I also realize that there is a workaround: NREL/api-umbrella-web@e47d6d1 and which is part of release already. So, imho, we are good to go.