[Documentation here](https://i2mint.github.io/http2py/)
`the_one_where_we_have_an_http_service_that_we_want_call_through_normal_looking_python_functions`
# (Http) Requests for humans
Tools to create python binders to http web services.
Here, we develop python data access to web content through http request such as web services or web pages.
The story is as follows: You found something on the web that you'd like to interact with.
* This could be data you'd like to have access to,
* or some actions you'd like to perform -- such as search, posting an article, buying some bitcoin, etc..
* If you're really lucky, someone's already written a python layer to do what you want to do.
* If you're just lucky, the resource comes with a clear interface definition that makes it
easy for you to write your own python for.
* If you're less lucky, you'll have to decipher some bad documentation of the API,
or even write your own bots, crawlers and parsers to get what you want.
We want to make that all easier for you.
What we'll focus on for now is the fundamental common aspect of making a python layer to the http requests.
"But... the excellent [`requests` library](https://requests.readthedocs.io/en/master/)
already provides the python wrapper to http!" you say. Yes, and we thank the `requests` developers for that.
It is indeed an excellent package that we won't have to write now!
We'd like to build from there, cover more annoying boilerplate, and get you closer, faster,
to the functionality you actually need:
Functions with the python types you're using in your code,
that responds with python objects you can directly use in your code.
The development of `requests`
(including the [recommended add-ons](https://requests.readthedocs.io/en/master/community/recommended/))
could be said to be facing the metal (raw http mechanics) and building interfaces with humans in mind.
By contrast, we want to face the human and build adapters to communicate with the metal.
That is, in our case, the fact that http is under the hood shouldn't even be visible (unless it needs to).
It's in honor of the inspiration of "designing for humans" that we extend requests' tag-line,
to "requests for humans".
# The approach
As always, we favor expressiveness, boilerplate minimization, separation of concerns, and a layered approach that
incrementally transforms and enhance to get us from where we are to where we want to be.
So for py2request, where are we and where do we want to be?
**What we have**: We have some http accessible resources. For instance, a perfectly well structured API
specification of a REST webservice, a very messy website, or anything in between.
**What we'd like**: A Python interface to these web stuff.
That is, we want to talk python to the resources, and have it talk python back to us.
Further, we want this conversation to be to the point; we don't want to have to say more than the exact necessary,
and don't want responses containing anything but exactly what we want and how we want it.
Finally, we'd like to get this with minimum effort -- letting default choices be made for us, but being able to make
our own choices if we want.
Is that too much to ask?
In the layered approach we'll go from function specifications, to functions returning python
Request objects, which we can then wrap further to create functions actually executing the request,
getting back a Response object, and wrap further to get the final python output type.
So the objects in this pipeline are:
* Specification
* Request
* Response
* Final python object
Raw data
{
"_id": null,
"home_page": "https://github.com/i2mint/http2py",
"name": "http2py",
"maintainer": "",
"docs_url": null,
"requires_python": "",
"maintainer_email": "",
"keywords": "webservice,http,requests,API",
"author": "Otosense",
"author_email": "",
"download_url": "https://files.pythonhosted.org/packages/ec/07/2c6db89f516f6a1491c6471094134157b54cbc2c2e52fcb7d606638c7169/http2py-0.1.29.tar.gz",
"platform": "any",
"description": "[Documentation here](https://i2mint.github.io/http2py/)\n\n`the_one_where_we_have_an_http_service_that_we_want_call_through_normal_looking_python_functions`\n\n# (Http) Requests for humans\n\nTools to create python binders to http web services.\nHere, we develop python data access to web content through http request such as web services or web pages.\n\nThe story is as follows: You found something on the web that you'd like to interact with. \n\n* This could be data you'd like to have access to, \n* or some actions you'd like to perform -- such as search, posting an article, buying some bitcoin, etc.. \n* If you're really lucky, someone's already written a python layer to do what you want to do. \n* If you're just lucky, the resource comes with a clear interface definition that makes it \neasy for you to write your own python for. \n* If you're less lucky, you'll have to decipher some bad documentation of the API, \nor even write your own bots, crawlers and parsers to get what you want. \n\nWe want to make that all easier for you.\n\nWhat we'll focus on for now is the fundamental common aspect of making a python layer to the http requests. \n\n\"But... the excellent [`requests` library](https://requests.readthedocs.io/en/master/) \nalready provides the python wrapper to http!\" you say. Yes, and we thank the `requests` developers for that. \nIt is indeed an excellent package that we won't have to write now! \n\nWe'd like to build from there, cover more annoying boilerplate, and get you closer, faster, \nto the functionality you actually need: \nFunctions with the python types you're using in your code, \nthat responds with python objects you can directly use in your code. \n\nThe development of `requests` \n(including the [recommended add-ons](https://requests.readthedocs.io/en/master/community/recommended/)) \ncould be said to be facing the metal (raw http mechanics) and building interfaces with humans in mind. \nBy contrast, we want to face the human and build adapters to communicate with the metal. \nThat is, in our case, the fact that http is under the hood shouldn't even be visible (unless it needs to).\n\nIt's in honor of the inspiration of \"designing for humans\" that we extend requests' tag-line, \nto \"requests for humans\".\n\n# The approach\n\nAs always, we favor expressiveness, boilerplate minimization, separation of concerns, and a layered approach that \nincrementally transforms and enhance to get us from where we are to where we want to be.\n\nSo for py2request, where are we and where do we want to be?\n\n**What we have**: We have some http accessible resources. For instance, a perfectly well structured API \nspecification of a REST webservice, a very messy website, or anything in between.\n\n**What we'd like**: A Python interface to these web stuff. \nThat is, we want to talk python to the resources, and have it talk python back to us. \nFurther, we want this conversation to be to the point; we don't want to have to say more than the exact necessary, \nand don't want responses containing anything but exactly what we want and how we want it. \nFinally, we'd like to get this with minimum effort -- letting default choices be made for us, but being able to make \nour own choices if we want.\n\nIs that too much to ask?\n\nIn the layered approach we'll go from function specifications, to functions returning python \nRequest objects, which we can then wrap further to create functions actually executing the request, \ngetting back a Response object, and wrap further to get the final python output type.\n\nSo the objects in this pipeline are:\n* Specification\n* Request\n* Response\n* Final python object",
"bugtrack_url": null,
"license": "Apache",
"summary": "Tools to create python binders to http web services.",
"version": "0.1.29",
"project_urls": {
"Homepage": "https://github.com/i2mint/http2py"
},
"split_keywords": [
"webservice",
"http",
"requests",
"api"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "ec072c6db89f516f6a1491c6471094134157b54cbc2c2e52fcb7d606638c7169",
"md5": "d0a3aed14b3afdd1dceb33baa53822dc",
"sha256": "ba7579191d94d3b76cc908d80612e2a58a583fbc0121eea309b21597eaf17d2e"
},
"downloads": -1,
"filename": "http2py-0.1.29.tar.gz",
"has_sig": false,
"md5_digest": "d0a3aed14b3afdd1dceb33baa53822dc",
"packagetype": "sdist",
"python_version": "source",
"requires_python": null,
"size": 26721,
"upload_time": "2024-01-16T14:38:36",
"upload_time_iso_8601": "2024-01-16T14:38:36.532240Z",
"url": "https://files.pythonhosted.org/packages/ec/07/2c6db89f516f6a1491c6471094134157b54cbc2c2e52fcb7d606638c7169/http2py-0.1.29.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2024-01-16 14:38:36",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "i2mint",
"github_project": "http2py",
"travis_ci": false,
"coveralls": false,
"github_actions": true,
"lcname": "http2py"
}
JSON
