API Hiring Checklist (Part 1)

When hiring an api architect or developer, there is a certain amount of knowledge they should have walking into a company (and no, it's not B-Trees).

And this knowledge differs based upon their skill level.

So I thought I would take some time to make a list of those skills and what they are for hiring managers...

API call flow

This is all the pieces of your api architecture and the ORDER in which they are called based on the request/response. Below see an example of Openapi maintainer not understanding a basic principle of call flow called 'internal redirects'.

Questions to ask

What is difference between internal redirect and external redirect?

Why would one use one over the other? Explain for both.

What is the gateway for and what is it's order in the call flow?

Which comes first, load balancer or gateway?

Explain latency between each request/response hop? Do tools increase latency?

Security (JWT, OAuth, Cors, RBAC/ABAC)

Unless you plan to have all your endpoints public, you need a solid understanding of all this methodology, how it works and how to implement. Relying on your gateway means any 'internal redirect' in the application (see Step Functions) will BYPASS ALL SECURITY at your gateway.

Questions to Ask

When do you send credentials?

What is difference between authorization and authentication?

How do you limit the data returned for an endpoint for two different ROLES? How do you request it differently for those two ROLES?

Explain why you would not want to send 'username' in the JWT? What determines when a token expires?

How do we whitelist frontends? Does that work with 'curl' and command line tools? How does your request need to be sent?

Caching

There are tools that handle caching but caching is used EVERYWHERE in your api application and SHOULD be as near your central version of truth (ie the endpoint) as possible. Putting your caching in your gateway means it can miss a large majority that redirects or uses 3rd party tools.

Questions to Ask

How do you get all your services to see the cache?

When do we want to cache the response in the call flow?

How do you avoid reading someone elses cached response?

Should cache be localized or centralized? Explain.

Tools

Many developers use tools without realizing the negatives to said tools as well as positives. For example, AWS services are all separate NETWORKS and to use them in conjunction means calling a Lambda will make 5-6 separate network calls (iam > gateway > lambda > dynamodb and back) thus prolonging the response and adding excess overhead. (NOTE : This is one of many reasons why Amazon has started dumping its services in favor of monoliths/applications.)

Questions to Ask

When would you use cloud services? When would you NOT?

What is a step function and what is it used for?

How do you integrate api calls/tests into your devops pipeline?

Configuration Management

Most people define a MILE_LONG OpenAPI document (instead of properly separating them out). They will create duplicate docs, leave out RULES( RBAC/ABAC) and generally create a mess that has no central version of truth.

Questions to Ask

What is difference between JSON Schema and OpenApi? When would you use one over the other?

What are the limitations of OpenApi?

Central Version Of Truth

Many people think this is the OpenAPI doc... it is not. The central version of truth in your apis would exist even without OpenAPI; it is your endpoints/controllers that define the rules. For example, mapping in:

Python

# The API endpoint
url = "https://jsonplaceholder.typicode.com/posts/1"

# A GET request to the API
response = requests.get(url)        

Springboot(Java)

    @GetMapping("/{id}")
    public User getUserById(@PathVariable Long id) {
        // ... retrieve user by ID
    }

    @PostMapping
    public User createUser(@RequestBody User user) {
        // ... create a new user
    }        

GoLang

func getUsersHandler(w http.ResponseWriter, r *http.Request) {
  // Get the list of users from the database
  users := getUsersFromDB()        

You can clearly see the RULES for request/response are MAPPED in config to the controller to create the 'endpoint'.

Questions to Ask

Where does the request go to get the resource? What is the endpoint?

How do you map api's to endpoints?

What classes get called PRIOR to calling the endpoint?

What classes/services/tools get called AFTER calling the endpoint

Conclusion

If you are hiring an api developer/architect, make sure they can DEMONSTRATE and explain the above. Otherwise you may find yourself with an evangelist as an architect (and not an actual developer).

Or you can always hire someone who understands these principles.

Stay Tuned for PART 2 where I answer these questions....