New answers tagged

1

Be consistent. A table can be conceptualized as a data structure or relationship, a type definition. It can also be considered a collection of objects. The former leads to singular names and the latter leads to plural names. It's only a headache if they are mixed. For example: create table person ( id int, given_name text, surname text ) The CREATE statement ...


0

I think pretty much all of these are used widely but I would recommend avoiding the more customized solutions. JWTs are widely used, for example but I've seen a few articles about their inherent weaknesses as a security solution. I think this is the wrong way to think about this. When considering security solutions you should consider your threat model ...


0

I am for the same answer as Jack; HEAD with 200 or 404. However you may want to validate more than the availability in your system. You may also need to validate the DNS for that email. Or you may have to validate a phone number while he does not identify one identity. In that case, you may want to introduce one availability resource: >> GET /...


0

An idea that we had was to take the tests from the previous version and run them against the current version to make sure that code that depended on the old tests would not break as the tests represent the behavior that the client code would depend upon. This means that people can't change existing behavior by modifying the tests (which would be a breaking ...


2

if you use hyphens, they can get treated as "minus" unless you bracket them - unaesthetic and extra typing... var t = json.phrase_stems.text-1; //error var t = json.phrase_stems["text-1"]; //ok But if you need to build the string, you need brackets irrespective var myTextNo = 1; var t = json.phrase_stems["text&...


0

I think the proper approach for making sure the APIs are not changed and the other 3rd parties won't be impacted after this update is writing Integration Test in your CI/CD Process. What is integration testing - [Read More]


2

You want consumer-driven contract (CDC) testing. Basically, your customers demonstrate how they expect to use the API in a way so that you can re-run their tests before you deploy a change to your code. (Beware: currently it is hard to search for "CDC tests" because you drown in covid-related results about genetic testing.)


0

Actually, I think it's better to have different APIs, My reason for this suggestion is if you have a limited number of products in stock, you might need to manage/reserve the stock from the "add to cart" step till the customer pays the invoice and if you don't do that and return an error to the customer due to unavailability of the product when he ...


3

Use cases which require separate payment screen from order: Payment initially succeeds but then fails or is taken back. The customer is in debit and needs to make a payment but the order has already been placed. Some admin charge or unexpected fee is raised against the account, the customer has make payment to settle, but there is no order. Customer is in ...


0

Limit API Testing to the API Service, Not the Underlying System There will be other points of view, but API testing should generally be limited to validating the existence of expected endpoints, authentication/authorization to the API itself (as opposed to auth against the back-end service behind the API), and validating the well-formedness of requests and ...


Top 50 recent answers are included