pyRest part 2: Hooking the API
Join the DZone community and get the full member experience.Join For Free
I've decided to hook the API in before I refactor the code to separate the web framework from pyRest, since I firmly belive in getting things working first and cleaning up after. I did create a namedtuple to hold basic response values so that the requesthandler function can be extracted later.
- The 'interesting' part looks like this
Response = namedtuple('response', 'status content') def requesthandler(method, *pathargs, **kwargs): """Main dispatch for calls to PyRest; no framework specific code to be present after this point""" if not method == 'get': return Response('500 Server Error', 'Not implemented') repo = hgapi.Repo('.') return Response('200 Ok', repo.hg_id())
..not much yet, but it responds to any GET request with the current Mercurial node id.
My intention is that the final result will be three separate parts - a routing/domain specific part that uses hgapi, pyRest proper which handles requests and autohooks up the routing, a CherryPy part which integrates with CherryPy and will need to be reimplemented for every web framework supported.
That will be at at least one update before that though, because next will be "autowiring" the routing logic. Code for the project is available at Bitbucket
Published at DZone with permission of Fredrik Håård, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Using OpenAI Embeddings Search With SingleStoreDB
What to Pay Attention to as Automation Upends the Developer Experience
Designing a New Framework for Ephemeral Resources
Micro Frontends on Monorepo With Remote State Management