BYU Web Service Manual
HomeToolsWeb Service manual Edit Page

Publish to WSO2

Now that you’ve used WSO2, it is time to add your API to WSO2, so that other people can use it too. WSO2 protects our APIs and makes them easier to consume.

The general tutorial for how to publish to WSO2 can be found here: https://developer.byu.edu/docs/publish-api/add-api-api-manager But we will be going through the process step by step.

Go to https://api.byu.edu/publisher (you will probably need to ask to be given access, Dan McNeece ought to be able to help). You should see something like this:

Click the “Add” button.

Then click the “I have an Existing API” bubble, then the “Swagger file” button, and and choose your swagger file.

Fill out the information for your API. The name should be --favorite-color, the context should be "--favorite-color/dev", and the version should be "v1". As you scroll down you should see a representation of what your API will do.

You may notice that it threw the “x-controllers” in there, but you don’t have to worry about them. Push “Save” and then “Next”.

Add the URL of your server on AWS as the endpoints (they should be the same). Then click “test” to make sure they are legit.

Our Server isn’t really going to be in Production, just development. The idea of Sandbox is that it is not connected to the real data.

Click “Save” and then “Next”.

Do NOT check the box “Make this the Default.” Checking this box may cause problems down the road for subscribers.

Select Unlimited for tier availability.

Select HTTPS ONLY as your transport. If you select HTTP, no one will be able to call your API.

leave the rest in the configurations section blank.

Click on Buisness Information. You are both the business owner and technical owner, so fill it out using your BYU email alias.

Now you are ready to save and publish! Click the button “Save & Publish.”

Nice! Your API is all ready to go… or is it??

Go to the API store and check it out (https://api.byu.edu/store/)

Type your first name into the search bar (or the full name of your API if you aren’t lazy like me)

Click on your API. Subscribe the same way you subscribed to the Persons API in the last module.

Then go to the API console and use your sandbox key.

Then you can test it out using the try it out feature. You will probably realize pretty quickly that the POST and PUT method don’t work, the GET and DELETE methods should work (if they don’t, you have a problem). We are going to take a moment now to talk about all the wonderful bugs in WSO2 (I got these two bugs and their solutions from John Bench, so even though people might point you to him, he doesn’t have any more information on the issue than this).

Bug 1-

You may have noticed that the difference between the methods that work and the methods that don’t is that the ones that work don’t use query parameters. As you can imagine, if all the query parameters didn’t work, then that would be a serious problem. This is due to WSO2 not accepting the query parameters because it is looking for something else (it kind of gets confused by the ‘?’). The standard way to fix this is to update your swagger document to have a path named “/?*” to your non-base-path. This can’t be used by the try it out feature, but it allows your normal calls to be recognizable.

Go back to https://api.byu.edu/publisher and pull up your API. Then click “Edit”

Then click “Edit Source”

That will take you to your swagger document. Things might be out of order and there might be a few things added, but that doesn’t matter. You might have some funny errors too, but don’t worry about them. Copy your PUT method.

Paste it at the end of your paths and modify the path like so:

Click save in the top left corner. Then click save at the bottom of the page. Then go to to the manage page and click “Save & Publish”

Now your put should work.

The base path is affected a little differently. The try it out function will never work until they fix the bug, and if you want to send a request to it using Postman or from an API, you need to put a ‘/’ before the question mark.

Bug 2-

It can’t take delimiter characters in the path or query, so to deal with that there was a work around made. Instead of putting the parameter like {parameter}, it needs to be done like this: {+parameter}.

It can get a little hairy so here are some websites you can check if you have problems:

https://developer.byu.edu/docs/debug-api/my-api-isnt-accepting-special-characters

https://developer.byu.edu/docs/debug-api

https://github.com/byu-oit/UAPI-Specification

Good luck!

Contributing Source Issue Tracker