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.
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.
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.