Turkiye API

What is Turkiye API?

Turkiye API allows you to retrieve data about the provinces, districts, neighborhoods and villages of Turkey (all or as much as you want), sort these provinces, districts, neighborhoods and villages (by name, license plate number, population, area covered, etc.), filter according to some characteristics of the provinces, districts, neighborhoods and villages. It is a REST API prepared for developers that you can do (such as showing only metropolises, showing districts with a population between 100000 and 500000).

What other features does Turkiye API have?

Includes URL Creator, documentation and example usage scenarios.

What is the technology stack of Turkiye API?

Turkiye API is a REST API that uses Node.js and Express.js without any database. (It uses JSON files as a database.) It uses Pug as view engine. It is hosted on Heroku.

What is the story behind Turkiye API?

I created it inspired by Rest Countries API and PokéAPI. What caught my attention was the lack of an API that prepares Turkey's provinces and districts (with some extra information). So, I created the Turkey API.

Do you have any plans for Turkiye API?

The v1 version seems to have started to lose its developability and maintainability. When I first started developing the project in 2022 (I had just started my first year of university at that time), the name of the project (and of course also the repository) was "Provinces of Turkey API". The reason for this is that during the first few months when the API was first developed, you could only retrieve province information (Also, this information consisted of only five properties: id, name, population, areaCode and isMetropolitan). Over time, I focused on fixing the bugs of the API and adding new features (one of them was districts). Over time, districts became a schema in their own right, just like provinces, but instead of being written separately with an ID-Key connection, these districts were written in the district arrays of the relevant provinces in the same json file. This is the first problem, I have largely solved this problem for v1, but there are still some problems. The second problem was that there was no support for query parameters at first. These parameters were added step by step over time (first added "name, offset, limit", then filtering parameters, then fields, lastly sort).

It is not easy to write the code from scratch without breaking the API requests of v1 users, however, I want to spare time for other projects and other work. That's why I'm taking a long break for this project. When the time comes, I will most likely start writing v2. Things I need to examine other sample APIs and also decide:

• Should I use database in v2 as opposed to v1?
• What kind of project structure should I create?
• Should I prefer snake_case instead of camelCase? (like area_code instead of areaCode)
• What kind of route structure should I use? (Should I use routes like /provinces/34/districts/1852 instead of separate routes for provinces, districts, etc.?
• Municipality support was not added to v1 because it would have been a bit complicated if I had added it.
• What kind of connection should there be between Schemas? (How exactly can we position the municipalities when there is an order like provinces > districts > neighborhoods + villages)
• fields property cannot set quadratic (or more nested) props, also sort property does not work for all fields. How can I find a solution to this?
• Many more things I can't think of right now.

Because of all this, this time I will try to improve myself in terms of learning and plan well this time. The project has come a long way from when it first started and has much more advanced capabilities. Frankly, I think I've added enough features and made improvements to last until v2. I need some time to realize the things I plan to do for v2, so I'm taking a long break. When v2 is released (if it is released) it will have better and more descriptive documentation, be more systematic and expandable. You can still submit your suggestions, requests, etc. by opening an issue on the Türkiye API GitHub page. you can write. In this case, I will also consider these for v2.

Best wishes!

This explanation has taken from the Last Considerations section of the README.md file in Turkiye API GitHub page.