hashgraph / hedera-mirror-node

Hedera Mirror Node archives data from consensus nodes and serves it via an API
Apache License 2.0
143 stars 111 forks source link

Topic REST API Endpoints utilize both singular and plural paths #700

Closed Nana-EC closed 4 years ago

Nana-EC commented 4 years ago

Detailed Description Currently our topic rest api endpoints fluctuate between using singular and plural paths for resource.

Current

We should be consistent in resource reference

Actual Behavior Resources use both singular and plural

Expected Behavior Resources are consistently plural or singular unless an exception is required

Solution Employ plural throughout and be consistent with most design standards and the rest of our current REST API's

Alternatives Make them singular. This would be inconsistent with the rest of the REST endpoints

Additional Context Add any other context about the problem here. Attach any logs here, if applicable.

Examples of popular REST API's https://developer.github.com/v3/ https://cloud.google.com/apis/design/resource_names https://developers.google.com/maps/documentation/urls/guide https://docs.aws.amazon.com/apigateway/api-reference/resource/ https://developers.facebook.com/docs/graph-api/reference https://developer.twitter.com/en https://www.instagram.com/developer/endpoints/ https://www.meetup.com/meetup_api/ https://developer.foursquare.com/docs/places-api/endpoints/ https://developers.soundcloud.com/docs/api/guide https://www.dropbox.com/developers/documentation/http/documentation https://developer.wordpress.org/rest-api/reference/

Most of them employ plural in general with an exception for singular where it's not necessarily a static resource being employed but a dynamic

apeksharma commented 4 years ago

There will be differences even in various popular api. That's why we should not refer many. It'll lead to quoting examples from references which support personal preferences. I'd prefer we don't have to get together and do that exercise many times. Let's do the following:

To that end, I +1 the second option in above list since it's a design guide documenting design rules (unlike others which are apis and we'll have to reverse the rules).

https://xkcd.com/927/