Learning Library

← Back to Library

Creating a REST API for SOA Service

Key Points

  • The tutorial walks through creating a new REST API in IBM API Connect by logging into the management portal, navigating to Drafts, and adding a new API with a custom title.
  • It configures the API to use HTTPS, consume and produce JSON (instead of the backend’s XML), retains the default security requiring an IBM client ID, and changes the default GET method to a POST to match the SOA service.
  • By uploading the WSDL (WISLE) file, API Connect automatically parses the available backend services and generates corresponding operations, such as “account inquiry” and “check request.”
  • The guide then shows how to manually build request and response definitions by adding each JSON property to the inbound “check request” and outbound “check response” models, ensuring the API translates between JSON payloads and the backend’s XML format while hiding the real backend URL from callers.

Full Transcript

# Creating a REST API for SOA Service **Source:** [https://www.youtube.com/watch?v=exZ1YP0jjug](https://www.youtube.com/watch?v=exZ1YP0jjug) **Duration:** 00:09:32 ## Summary - The tutorial walks through creating a new REST API in IBM API Connect by logging into the management portal, navigating to Drafts, and adding a new API with a custom title. - It configures the API to use HTTPS, consume and produce JSON (instead of the backend’s XML), retains the default security requiring an IBM client ID, and changes the default GET method to a POST to match the SOA service. - By uploading the WSDL (WISLE) file, API Connect automatically parses the available backend services and generates corresponding operations, such as “account inquiry” and “check request.” - The guide then shows how to manually build request and response definitions by adding each JSON property to the inbound “check request” and outbound “check response” models, ensuring the API translates between JSON payloads and the backend’s XML format while hiding the real backend URL from callers. ## Sections - [00:00:00](https://www.youtube.com/watch?v=exZ1YP0jjug&t=0s) **Untitled Section** - ## Full Transcript
0:00API connect video 0:04series this presentation will show you 0:07how to create a rest API to a SOA 0:13service begin this construction by 0:16logging into the 0:18dashboard of your API 0:21connect management 0:24portal click the menu icon and then 0:29click Direct 0:34drafts once you arrive at the drafts 0:37screen click on 0:41apis click plus to add a new 0:46API in the ensuing dialogue box enter a 0:50title for the new 0:53API and then click add this brings you 0:57to the design screen for the new 1:01API going down the screen we come to 1:06schemes which we must use 1:09https if we are going to use this on Blu 1:13miix or any public 1:19Cloud this will consume application Json 1:24and produce application Json as opposed 1:27to the XML that the backend SOA is is 1:33expecting we leave the security 1:35definitions in place this will require 1:39any application to provide an IBM client 1:43ID under paths which is the path that 1:47the user of the API will invoke we will 1:51change that to something that we will 1:53then publish to the users of this new 1:57rest API they will never see the real 2:02URL of the actual back 2:11end this currently is set up by default 2:14as a get however because this is a SOA 2:18back end we do want a post rather than a 2:22get and we will not use the get so we 2:26delete it 2:34we now must create a set of 2:37services that actually represent the 2:39back 2:41end we do this by uploading a wisle 2:46file here we look at the actual wisd 2:49file and we see under the wisd 2:52definitions the name space of the 2:55backend SOA resource and a a check 3:01request xsd and a check response 3:06xsd for now however all we need to do is 3:10upload the 3:13wisle and the wisle is pared 3:15automatically and shows you the services 3:18that are available we pick the one 3:21service that we want to use here this 3:24automatically creates two Services an 3:27account inquiry and a check request 3:29which which are defined in the 3:32wisle now we go create the definitions 3:35that are based on the inbound Json 3:41payload we begin to create the name of 3:45the definition which in this particular 3:47case will be the Json check 3:50request and now we must populate the 3:54name of this object with the various 3:57properties 4:08so we start by defining the first of the 4:13properties here we see the inbound Json 4:17payload for 4:26reference you will need to create all of 4:29these properties in the definition that 4:32we are creating for the API 4:37connect so here we create pay account 4:50name now I'm not going to show you how 4:53we do all of these you can understand 4:55how you make those when you're all done 4:56it'll look something like this notice 5:00that this continues to add new 5:03properties to the top of the list rather 5:05than the bottom of the 5:08list we'll now create the definition for 5:11the 5:17response just as before we see an 5:21example of what the Json check response 5:25is that we want to send to the original 5:28caller of the AP 5:31I so we have a check 5:34response and once again we walk through 5:38the elements that are in the outbound 5:40Json 5:42payload one by one and create these 5:45properties and we won't walk through all 5:48of those particular steps once you're 5:51done you have these two definitions 5:54check response and check request and we 5:56have these two services that came from 5:59the wisd 6:01now we assemble our API logic click 6:06assemble and then on the assemble screen 6:09click data 6:12power then remove the invoke that we 6:15will not 6:18use once you create a service you can 6:22now simply drag the service up onto the 6:26assembly line and because it knows that 6:30you created this service from a wisel 6:33that represents a backend service it 6:35automatically creates the two maps the 6:40maps translate or map the Json elements 6:47that come from the 6:48request to the XML elements that the 6:52backend Sea Service is 6:55expecting and here you can see that 6:57there's quite a a list of these possible 6:59objects that again came from the wisle 7:02but we want the one that we 7:07created here we are now at the input map 7:11you'll notice on the left is the 7:13definition we created and on the right 7:16is the XML definition that came out of 7:19the whsle now we simply drag and connect 7:24the various elements together 7:31we have to repeat this process in order 7:34to do the back end or in order to deal 7:38with the response coming from the back 7:40end once the SOA back end has 7:46responded so we proceed the same way we 7:51create the Maps using the drag androp 7:54capabilities of the user interface 8:07once this is 8:14complete we can now go and arrange 8:20to set up the actual invocation which is 8:24in between the two maps it's a good idea 8:27to save it first so that the invocation 8:30can show you any warnings that happen to 8:33be 8:35there the target URL is coming directly 8:39out of the 8:40wisle you may need to change this URL 8:44depending 8:46on how you built your back end or where 8:51you placed your back 8:56end and examination of the remaining in 8:59inputs to the invoke show that we are 9:02only using the 9:07defaults click all apis in the upper 9:12leftand corner to return to the list of 9:14all available 9:18apis your new rest to SOA API is now 9:23available to publish in any product that 9:27you 9:28choose for