I stumbled onto this via Twitter, and I agree wholeheartedly with your suggestions.
Two things leap out at me however:
Your API definition for accounts is absolutely not REST.
This is OK.
Most "REST" APIs are not REST in the sense that Roy Fielding defined Representational State Transfer in his PhD thesis. Most miss out at least the discovery part - you're really not meant to ascribe meaning to a URL, instead just discover them via hypermedia. The fact I even said "hypermedia" in a description of APIs is probably enough for people to look blank.
As a result, most REST APIs are built around only the network side of REST, rather than the hypermedia bits. This means that GET is always idempotent and so on. And URIs represent actual resources - if you PUT something to a resource, you can later GET the same thing (modulo other operations). It's this that represents a broader departure from REST in your design.
A more traditional REST API would have transactions processed by POSTing them to the account (perhaps), and result in a new URI for the transaction record itself. In your outline, you're PUTting continuously to the same URI. Performing a GET won't give you back what you PUT there before.
That's not, however, to say that your design is therefore "wrong". PUTting transactions you can no longer GET will work just fine - individually, the verbs all operate properly. It's a perfectly good design, and conforms to how HTTP itself works.
REST is often treated as the one true way of HTTP API design - it's held in almost religious fervour, despite, as I say, most REST APIs actually not following REST. But as you demonstrate, there are other ways of designing HTTP-based APIs, and they may well be a better fit for the business problem at hand.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I stumbled onto this via Twitter, and I agree wholeheartedly with your suggestions.
Two things leap out at me however:
Your API definition for accounts is absolutely not REST.
This is OK.
Most "REST" APIs are not REST in the sense that Roy Fielding defined Representational State Transfer in his PhD thesis. Most miss out at least the discovery part - you're really not meant to ascribe meaning to a URL, instead just discover them via hypermedia. The fact I even said "hypermedia" in a description of APIs is probably enough for people to look blank.
As a result, most REST APIs are built around only the network side of REST, rather than the hypermedia bits. This means that GET is always idempotent and so on. And URIs represent actual resources - if you PUT something to a resource, you can later GET the same thing (modulo other operations). It's this that represents a broader departure from REST in your design.
A more traditional REST API would have transactions processed by POSTing them to the account (perhaps), and result in a new URI for the transaction record itself. In your outline, you're PUTting continuously to the same URI. Performing a GET won't give you back what you PUT there before.
That's not, however, to say that your design is therefore "wrong". PUTting transactions you can no longer GET will work just fine - individually, the verbs all operate properly. It's a perfectly good design, and conforms to how HTTP itself works.
REST is often treated as the one true way of HTTP API design - it's held in almost religious fervour, despite, as I say, most REST APIs actually not following REST. But as you demonstrate, there are other ways of designing HTTP-based APIs, and they may well be a better fit for the business problem at hand.