Tuesday, November 21, 2017

CA API Policy Manager - Revision History

CA API Policy Manager is the user interface for the CA API Gateway. It is used to construct web service and XML application policies, manage policy users, configure identity bridging, and configure, audit, and monitor the CA API Gateway. Pretty useful tool, though it's a "eighties" thick client. 

It has tons of functions though, and they become quite useful at times. Today, a developer in my client's side changed something to an existing API, but couldn't tell me exactly what he has changed. 

Well ... typical. Vendors are paid to spend time to discover/explore/clean-up what has been messed up.  

Luckily, the Policy Manager has a Revision History to each API.

It can show a history of the changes made. What's best is one can choose 2 historic APIs and make comparisons.

What's even better is it can pin-point which assertion(s) within the API has been modified. A visual output in RAW XML format can even be shown.

This function saves me big time!


Thursday, November 2, 2017

API Slug

 I was playing with Tyk since they are offering 50.000 API calls / day FOC. What can you ask for?

While creating a test API, I came across a term "API Slug". What's that?

API IDs are internally unique but hard to remember. These are not useful for users, so you can replace them with a slug.

I find this developer friendly, as opposed to GUID as shown below.

Tyk was built because other open source API Gateways in the market come with dependencies and bloat, attempting to be too many things to too many people. Tyk is focused, simple and does one thing well - protecting your API from unauthorised access.

Another open source product ... let's see how long they will stay being open source.

These days, I make it a habit to fork frequently. You never know when the source will be closed.

When $ comes and put on your table, let's see whether or not you'll stay true to yourself - the original dream of building a whole-class open source product for the open source community.

We are all human beings.


Saturday, October 28, 2017

Should we allow modification of EULA?

In CA API Developer Portal, when an API consumer wants to subscribe to a published API, he/she has to accept the EULA (End-User License Agreement). I believe this is the same for all other products out there.

So a customer of mine asked me the other day why he is not able to edit the default EULA that comes with the portal installation. Note: these are random texts (as shown below) and customer wants to go-live, thus he needs to modify the EULA proper.

He also created a new EULA and tried to change the default EULA to this new one. But he was not allowed to do so.

Bug with the product? No.

We found out that he has already created applications and assigned some APIs to these applications. Now, when a consumer adds an API to his/her application, he will be prompted to accept the Terms and Conditions as stipulated in the EULA.

Once accepted, from an audit point of view, this particular EULA shall not be changed by another party. As such, CA API Developer Portal implements this "disabled" function.

I think this is a great feature. It covers the benefits of both parties - API Publishers and API Consumers.

I have seen other software vendor asking customers to sign a paper-form EULA. But within the EULA, it points to a hyperlink with more terms and conditions. In one case, a contract was signed in year 2016. In Sep 2017, customer went to the site and realized the terms and conditions had been updated (latest modified date was May 2017) without notice.

This is bad practice!


Friday, October 27, 2017

API Design & Implementation Tips

I was attending CA Partner Momentum held in Singapore this week. We had John flying in from Australia to conduct the event for us.

Some tips from John which I think are useful for field staff like us.

  1. Recommend agile approach 
  2. Collaborate with customer - get 1 dedicated person from customer's side to work 
  3. Minimum viable product 
  4. Select a simple API 
  5. Generate test case first (POSTman) 
  6. Use Gateway to emulate backend 
  7. Share test cases with client as early as possible 
  8. Show progress against test cases 
  9. It's ok for customer to change their mind (embrace change - but ask for something in return) 
  10. Leverage API Academy for questions around strategy


Friday, October 20, 2017

CA API Developer Portal Sign Up Form - Organization Name missing!

A customer of mine wanted to add Organization Name (make it mandatory also) to the Sign Up form. Just a few days prior to meeting with him, I was playing around with CA API Developer Portal. I do remember that Organization Name is actually available, but it was displayed as Title on the Sign Up form.

I confirmed via the admin console.

The issue is with the naming “Title”. It should be “Organization Name”. The UI should display Field Name, instead of Field ID. This could be a bug with the product.

This field can also be made mandatory by clicking on “Make this field required?”. I tested and it works in my labs.

With regard to the "bug", CA Support came back with a solution. 

Navigate to /xml_content/phrasepacks/v3. Edit dashboard-display.xml.

*** look out for title and description keys and make changes there.
*** make sure you are in common form phrases section 


Now, customer also asked how he can rename the wordings "I accept the disclaimer".

It's actually residing in the same XML under the tag "AcceptedDisclaimer". 


Tuesday, September 26, 2017

What is Serverless APIs?

Yet another buzz word - Serverless, when it actually means Cloud Platform / PaSS. 

- No servers to provision or manage
- Scales with usage
- Never pay for idle
- Availability and fault tolerance built in

With it, comes yet another term ... Serveless APIs.


APIs vs Microservices

I talked about the new trend in API - Microgateway and the often used buzzword "Microservices".

This slide says it all ... courtesy of Matt McLarty from API Academy. #APIWorld17


Wednesday, September 20, 2017


One Identity recently launched Starling Two Factor Authentication, a SaaS-based solution.

It solves the password problem without the capital costs or increased infrastructure management that you might incur with traditional on-premises solutions. With an easy to use dashboard for administrators and flexible authentication options for end users, Starling Two-Factor Authentication enables organizations to quickly and easily verify a user’s identity.

Starling Two Factor Authentication is actually based on Authy.

The nice thing about Authy is that it provides REST APIs which is useful for application integration which requires 2-Factor authentication. e.g OneTouch APIPhone Verification API

Cool stuff!