4 ms·
How I've addressed the transaction issue in the past is to expose it specifically as a transaction. For instance, POST /posts/transactions would contain a list
by drj077 10y ago
How I've addressed the transaction issue in the past is to expose it specifically as a transaction. For instance, POST /posts/transactions would contain a list of transformations to /posts and will receive a transaction id as a response. The id can be polled for success (/posts/transactions/:uuid) or results can be pushed to a browser. It is more work to be able to roll that back if one fails, but that's a coding issue not so much an API one.
I'd love some feedback on this approach. How do other people allow efficient mass changes?
- PaulHoule 10y agoThis type of approach can be great. It is parallel to the idea to the "business is an exchange of documents", and the documents represent "transactions" in the sense of "an invoice", "a packing slip", "a deposit slip", "an order", etc.
- seagreen 10y ago> "business is an exchange of documents" Did you just make up this phrase? It's really good!
- pbh101 10y agoYou would probably like reading [1] by Dan North. [1]: https://dannorth.net/classic-soa/ https://dannorth.net/classic-soa/
- seagreen 10y agoImagine you want to implement a vacation-booking service as part of an enterprise system. The first step is to remove any reference to computers or modern technology. This will allow you to concentrate on the business objectives of the service, without getting sidetracked by technological considerations. In other words, it enables you to separate the “what” from the “how.” That's pretty great advice.
- PaulHoule 10y agoI've been saying it for a while. I talked to the developers of this product about a decade ago: https://www.kuali.org/kfs https://www.kuali.org/kfs and that was the thinking behind how that system was built. Also this is the paradigm behind http://www.enterpriseintegrationpatterns.com/ http://www.enterpriseintegrationpatterns.com/ and it must predate the computer.