has redundant (and confusing) path prefixes. Specifically, the /put/ and /get/ prefixes are redundant with the HTTP method, and in the case of /put/ is actually confusing because the POST method is used instead of PUT.
The Richardson Maturity Model https://martinfowler.com/articles/richardsonMaturityModel.html gives a theoretical framework for why having verbs in the route is bad practice (http verbs are for verbs, paths are supposed to be nouns). In practice, when implementing the routing for the da server, it means I need duplicate routes for /put/commitments and /get/commitment, whereas this should have the same route (just commitment) and router will allow both GET and POST methods against it.
Describe the solution you'd like
Would like to clean up the routes to look like
POST /<hex_encoded_commitment>
POST /
GET /<hex_encoded_commitment>
or perhaps to be more clear and self-documenting
POST /keccak/<hex_encoded_commitment>
POST /generic
GET /<hex_encoded_commitment>
Can make this change and keep the old routes if we want to maintain backward compatibility.
Is your feature request related to a problem? Please describe.
The altda server spec
has redundant (and confusing) path prefixes. Specifically, the /put/ and /get/ prefixes are redundant with the HTTP method, and in the case of /put/ is actually confusing because the POST method is used instead of PUT.
The Richardson Maturity Model https://martinfowler.com/articles/richardsonMaturityModel.html gives a theoretical framework for why having verbs in the route is bad practice (http verbs are for verbs, paths are supposed to be nouns). In practice, when implementing the routing for the da server, it means I need duplicate routes for /put/commitments and /get/commitment, whereas this should have the same route (just commitment) and router will allow both GET and POST methods against it.
Describe the solution you'd like
Would like to clean up the routes to look like
or perhaps to be more clear and self-documenting
Can make this change and keep the old routes if we want to maintain backward compatibility.
Describe alternatives you've considered
Additional context