Azure API management is without any doubt a great tool to manage your APIs catalog but you can have some surprise about undocumented restrictions.
Issue demonstration Let’s take a real quick example. Try to create a new API and upload this OpenAPI specification:
openapi: 3.0.1 info: title: My super API version: 1.0.0 paths: /contracts/[contractId]/versions/[versionNumber]/administration/contact-informations: get: responses: 200: description: Valid response content: {} /contracts/[contractId]/versions/[versionNumber]/administration/contact-informations/[contactId]: get: responses: 200: description: Valid response content: {} The initial upload should be successful.
In my previous post I talked a little bit about the lost update problem which can be minimized when working with task based API. But you can never consider this problem as totally solved while you do not lock your data!
So first, let’s remember the issue.
Lost update Let’s say we have an app to manage the grocery list for a family, a classical web application with a web API behind it.
Task based and CRUD based are two different approaches you can encounter when you’re using an user interface. But besides the UI itself, you also have to choose between the same options when you build your API.
While task based is widely adopted when we talk about UI, it’s not always the case when we talk about the API.
In this post, I will present you what’s the difference between task based and CRUD based plus the benefits/drawbacks of each.
If you’re a web developper, you probably encountered CORS issues a couple of times and, even if it’s a well known issue in the web environment, it’s not always deeply understood how and why it occurs.
Understanding what’s CORS and the issues it can bring to your development is nonetheless important if you do not want to waste a lot of time in some silly situations…
When can I encounter CORS issues?
Mithril