Hydal

Product comparison site for electrical goods, currently has 350,000+ products with detailed specifications, and 27,000+ prices.

Right now UK only, but we have prices for 27 regions, and just now getting retailer prices sync'd up.

It's an electronic product database, where you can search through products and see all of the detailed specifications about each product. Has an API as well.

Currently integrating electronic news / reviews that will be linked to products.

- https://wrkout.xyz/ (exercise database api with images and videos) - https://github.com/wrkout/exercises.json (open source exercise dataset)

If they are of any interest / help

Each exercise comes with instructions, images and videos for demonstration purposes, showing the muscles worked.

All exercises are currently being translated into 40+ languages.

Comments URL: https://news.ycombinator.com/item?id=43068556

Points: 1

# Comments: 0

The purpose of this question/dicussion is not, how to version an API in the sense of, do you use `Version Headers` (this is my prefered option) or do you make it a url path e.g. `/api/v1/resource`, but rather how to version an API within the actual code of the API.

I have read a lot of articles about this, many of which have given possible solutions such as:

1. Having route folders labeled by their version number, then manually creating routes for each of these versioned folders. e.g. routes/v1/authRoute & routes/v2/authRoute

2. Defining in the route which version each route specific function is for. e.g. routes/auth & within auth v1: function() and v2: function

3. Programmatically generating the routes, based on the file structure of the routes folder e.g. routes/v1/auth and routes/v1/1.0/auth would end up being /app/v1/auth and app/v1/1.0/auth

So really, l was wondering, how do companies from big to small actually managed this without requiring a lot of manual effort.

Comments URL: https://news.ycombinator.com/item?id=9189854

Points: 2

# Comments: 2