We’re working on a more detailed follow up to the . As part of the follow-up, I’m looking into the APIs offered by ASX100 companies and, for no scientific reason, chose to start with an analysis of . high-level research we did into APIs and the ASX100 NAB’s developer portal This post isn’t a strict analysis, rather it’s a sharing of thoughts as I step through NAB’s API with a longer view of gaining a better understanding of API best practices in the wild. Overall, NAB’s API is surprisingly good for a bank. Easy to follow, easy to get started. First Impressions and Portal Home Page First impressions of NAB’s API are promising. Language is one of being product-led – “register, experiment, go-live” and “open beta”. There is even a hackathon tab.The registration link and documentation links are prominent and easy to navigate. You get the feeling that starting to use it will be straightforward.I get the sense that this is a modern API designed for developers. Actually a little surprised/impressed and excited to play around with it. Registration The registration process for NAB had a simple form that only required the most essential fields. It didn’t even ask for an organisation or phone number (quietly impressed). The process overall was: Simple registration form (5 fields) – the name fields could be combined but that’s nitpicking Verify my email addressLogin The whole process took under 5 minutes. Getting Started As soon as I logged in I could easily see where to get started. I clicked Getting Started and found my Sandbox API Key. You might wonder why this is worth noting, it’s because many APIs, especially those offered by enterprises and enterprise software providers are bizarrely not this straight forward. I was able to query NAB locations (i.e. where there is an ATM) within 2 minutes in postman, but I wasn’t easily able to start querying anything that required authentication in postman. When I put my x-nab-key in, I got back “400 Invalid Request” and when I tried the sandbox OAuth flow, I had some errors come back. I could see how to resolve this by writing actual code. API Documentation The API endpoint documentation is broken up in an understandable way. It breaks up the API into some high-level, logical areas like Locations, FX and Accounts. It then uses verbs for the titles of the API endpoints themselves (e.g. “Get List of Accounts”) making it easy to see what I can do and what is relevant for me. Verbs – like “Get” or “Delete” – are generally the actions or tasks that a developer is trying to do. So using language like this matches what they need. Sample code is provided in multiple languages/technologies: json, curl, java. There wasn’t a way to test the endpoints inline. API Design URL Standard The NAB API follows the RESTful standard closely. Using the HTTP verbs to describe the action being taken – GET – and the URL to describe the resource the action is being applied to – e.g. GET …/accounts/ This makes the APIs easy to follow. Other APIs sometimes include the verb in the URL itself or don’t follow any standard. The NAB API is a good example of a restful API in the wild. Variable/Parameters Names The NAB API’s parameter and variable names were mostly easy to follow and understand. They were usually full names that described themselves. There were some exceptions to this like the “ ” attribute on the endpoint. It’s unclear what this variable is. apca Get List of Accounts There were some redundant descriptions – e.g. the attribute has a description of “ ” adding no additional information or insight into what this attribute is, what it’s used for or how it’s formed. accountToken Account Token Versioning There is a bit of confusion on the NAB API endpoints with versioning. The version is listed in both the URL and at the end in the query parameters. On the Get List of Accounts endpoint, the endpoint seems to be both version 2 and version 1 at the same time. The variables need different names or the version in the query parameters needs to be removed (what is its purpose?). Going Live to Production I didn’t go down the path of getting production access due to time constraints on my part. Product Strategy After walking through the API I stepped back, sipped my coffee and contemplated the API more broadly through the lens of the API as a digital product. Some thoughts: The API appears to be the same API they are using internally for their own digital experience. This is exactly what you want as a company and a third-party developer. The API appears to be useful to startups more established partners making it more likely to be available in the long run. On the home page, some startups are shown but the functionality appears useful by an enterprise looking to incorporate NAB data into their digital product. and

The Sandbox

Flow

2022 - HackerNoon Contributor of the Year - Agile

2022 - HackerNoon Contributor of the Year - Agile Software Development

Don't talk to McKinsey, talk to Terem

Nominated for 2022 - HackerNoon Contributor of the Year - Agile

Nominated for 2022 - HackerNoon Contributor of the Year - Agile Software Development

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

NAB’s API: The Big Reveal

Too Long; Didn't Read

Coins Mentioned

Scott Middleton

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

NAB’s API: The Big Reveal

Too Long; Didn't Read

Coins Mentioned

Scott Middleton

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES