-
๐ shorty
-
๐ custom_shorty
-
๐ custom.py
-
-
๐ error_msgs
-
๐ errors.py
-
-
๐ providers
-
๐ bitly
-
๐ bit_ly.py
-
-
๐ tinyurl
-
๐ tinyurl_com.py
-
-
๐ provider_short.py
-
๐ bitly
- ๐ static
-
๐ templates
-
๐ swaggerui.html
-
-
๐ api.py
-
๐ app.py
-
๐ custom_shorty
-
๐ tests
-
๐ functional_tests
-
๐ conftest.py
-
๐ test_shorty_api.py
-
-
๐ unit_tests
-
๐ test_custom_shorty
-
๐ test_custom.py
-
-
๐ test_providers
-
๐ test_bitly
-
๐ test_bit_ly.py
-
-
๐ test_tinyurl
-
๐ test_tinyurl_com.py
-
-
๐ test_provider_short.py
-
๐ test_bitly
-
๐ test_custom_shorty
-
๐ functional_tests
๐ณ Dockerfile
๐ LICENSE
๐ README.md
๐ requirements.txt
๐ run.py
๐พ virtual_enviroment.sh
Your mission, should you choose to accept it, is to build a microservice called shorty
,
which supports two URL shortening providers: bit.ly and tinyurl.com.
You don't need to actually sign up to these providers, just implement their API. The
service exposes a single endpoint: POST /shortlinks
. The endpoint should receive
JSON with the following schema:
param | type | required | description |
---|---|---|---|
url | string | Y | The URL to shorten |
provider | string | N | The provider to use for shortening |
The response should be a Shortlink
resource containing:
param | type | required | description |
---|---|---|---|
url | string | Y | The original URL |
link | string | Y | The shortened link |
For example:
{
"url": "https://example.com",
"link": "https://bit.ly/8h1bka"
}
You are free to decide how to pick between the providers if one is not requested and what your fallback strategy is in case your primary choice fails. Your endpoint needs to return a JSON response with a sensible HTTP status in case of errors or failures.
So, shorty
shortens the url given as a request using as a default
provider the tinyurl provider. If the user decides to choose the provider though he's free to do so, and if both providers are unavailable for any reason, shorty uses a custom built in short() function to shorten the url requested.
Example:
{
"url":"https://www.example.com/",
"provider":"bitly"
}
Shorty
checks for every possible mistake the user might do and provides a useful message for the user alongside an appropriate HTTP status code.
An example of a possible error message:
{
"Error": "[!] Request must be provided in json format.",
"Usage": [
{
"url":"https://www.example.com/",
"provider":"bitly"
},
{
"url":"http://example.com/",
"provider":"tinyurl"
},
{
"url":"http://example.com"
}
]
}
After all shorty
responds back if everything's ok.
Response Example
{
"url": "https://example.com",
"link": "https://bit.ly/8h1bka"
}
- Create a Python env (using Python 3.6+) and install the requirements.
- Build the
POST /shortlinks
endpoint. We've provided a skeleton API usingflask
. - Write some tests using
pytest
.
-
Implemented the POST /shortlinks endpoint where the basic functionallity of the API resides.
-
Implemented the GET /shortlinks endpoint where the user gets informed with a usefull error message, that only POST method works with the API.
-
Implemented the GET /shortlinks/docs endpoint where, you can find rendered an HTML page, where basically resides a swaggerUI documentation for the API.
-
Implemented both API providers with the user functionallity to choose whoever he/she wants and if none is chose then a default one handles the request, as well as a custom short() function where the requested url can be shortened, if for any reason the providers fail.
-
Implemented both integration (functional) and unit tests, for whatever was needed to be tested in the API.
-
Provided a Dockerfile as well as a bash script to run the virtual enviroment.
You can run the API locally either with python virtual enviroment
or by building ๐ท the provided docker
image.
Open up a terminal and run the provided bash script inside the root directory
of the project:
$ ./virtual_enviroment.sh
Open up a terminal again inside the root directory
of the project and run the following:
# 1. To build the image
$ sudo docker build --tag shorty:latest .
#2. To run the image
$ sudo docker run -p 5000:5000 shorty
Now, after running the API successfully, you can install Postman on your machine and play with the API, by posting your request at the /shortlinks endpoint! Also you can open up a browser and type in: localhost to check the swaggerUI documentation interface!
Finally you can check shorty's
validity by going into the tests
directory and by opening up a terminal inside that directory and provide the following command in the workink shell:
$ pytest -v
You should deliver your solution as a Pull Request in your repo. Document your design choices and anything else you think we need to know in the PR description.
In a nutshell, we're looking for tidy, production-quality code, a scalable design and sensible tests (unit tests, integration tests or both?). Imagine that your code will be read by other developers in your team โ keep them happy :-)
Flask
: http://flask.pocoo.org/pytest
: http://pytest.org/latest/virtualenvwrapper
: https://virtualenvwrapper.readthedocs.io/en/latest/HTTP statuses
: https://httpstatuses.com/
ยฉ๏ธ 2020-2021, Andrew Pappas