QQ. While I understand the "hiding" how many customers we have via not exposing auto-incrementing PKs may be important to business people, don't these two statements directly conflict?
Security through obscurity is the idea that something hidden is therefore secure.
If your IDs are simply sequential, then you are at best inadvertently leaking information about your business that you might not want people to know and at worst creating a security incident in waiting.
Given you have secured your Api isn't that a moot point about exposing PKs? Any special knowledge of a system is as you first pointed out inconsequential in a well-built/designed/implemented Api right? Our security makes special knowledge about a system DOA?
The non-autoincrementing PKs only seem to be useful in an insecure Api strictly, almost like a crutch?
Fun fact. When working with Stripe API, you come across a ton of unnecessary empty fields. When you just want to get the same information as on the payment page, you have to study a bunch of nested objects.
The calculated amount of VAT for the current payment, for example, you will not receive anywhere at all! This is the official answer from support. This information is simply not available anywhere, all you can do is subtract the paid amount from the cost of the product.
Great architecture, great docs page, great articles. But awful experience in real life.
Thanks for the feedback! Can you provide examples of unnecessary empty fields? I'd like to flag those to the team.
It's true that you can't get calculated VAT directly from a PaymentIntent, we actually recommend that you store the Tax Transaction ID as metadata on your PaymentIntent so you can retrieve it later.
In your case however it appears that you're using Checkout Sessions, where you can get the tax amount after the fact, although you'll need to expand the breakdown field to get the details.
This level of HTTP based API is on level of web 10 year before. Like using POST to update data, it's already overdue. Flat response object it's not descriptive enough. There is no content negotiations. Your human approach heavily depends on excellent documentation. It's definitely somewhere around level 1 on RMM. I agree on UUID, but adding prefix doesn't seems right. It carries noticable complexity to backend to use uuid on DAL and then enchant ID with prefix. Which appears in log at what form? There was good comment, that this approach make business manager happy. It's trivial, and business oriented. But there is much more API could and should do. For example for each API release, even for minor, must be code review on client side, to check what was added/changed and find what a data means in documentation. The message could be more self descriptive. This is definitely good start, but for good API it has a lot of work ahead.
Top comments (10)
Love this post! Would definitely welcome more along this line from the Stripe team!
Great series Paul, really loving these posts!
Love the concepts of this article.
QQ. While I understand the "hiding" how many customers we have via not exposing auto-incrementing PKs may be important to business people, don't these two statements directly conflict?
Given you have secured your Api isn't that a moot point about exposing PKs? Any special knowledge of a system is as you first pointed out inconsequential in a well-built/designed/implemented Api right? Our security makes special knowledge about a system DOA?
The non-autoincrementing PKs only seem to be useful in an insecure Api strictly, almost like a crutch?
Thanks for the article and tips!
Fun fact. When working with Stripe API, you come across a ton of unnecessary empty fields. When you just want to get the same information as on the payment page, you have to study a bunch of nested objects.
The calculated amount of VAT for the current payment, for example, you will not receive anywhere at all! This is the official answer from support. This information is simply not available anywhere, all you can do is subtract the paid amount from the cost of the product.
Great architecture, great docs page, great articles. But awful experience in real life.
Thanks for the feedback! Can you provide examples of unnecessary empty fields? I'd like to flag those to the team.
It's true that you can't get calculated VAT directly from a PaymentIntent, we actually recommend that you store the Tax Transaction ID as metadata on your PaymentIntent so you can retrieve it later.
In your case however it appears that you're using Checkout Sessions, where you can get the tax amount after the fact, although you'll need to expand the
breakdownfield to get the details.This level of HTTP based API is on level of web 10 year before. Like using POST to update data, it's already overdue. Flat response object it's not descriptive enough. There is no content negotiations. Your human approach heavily depends on excellent documentation. It's definitely somewhere around level 1 on RMM. I agree on UUID, but adding prefix doesn't seems right. It carries noticable complexity to backend to use uuid on DAL and then enchant ID with prefix. Which appears in log at what form? There was good comment, that this approach make business manager happy. It's trivial, and business oriented. But there is much more API could and should do. For example for each API release, even for minor, must be code review on client side, to check what was added/changed and find what a data means in documentation. The message could be more self descriptive. This is definitely good start, but for good API it has a lot of work ahead.
stripe documentation team can learn from you, FYI great artical.
Though it is interesting
awesome