I ran endpoints example in aws but it is not accessible outisde the ec2 instance. But when I tried running other applications it is accessible so it is not the problem of security groups related issue

When I give simple post request I have the following error

{
  "errno": 404,
  "errmsg": "/Foo not found because of TypeError \"not indexable\" on call.py:278"
}

my controller is as follows

class Foo(Controller,CorsMixin):
    def GET(self): pass
    def POST(self,**params):
        return "bang"

allow param to also do path bits, so something like:

decorators.param("/action", type=int)

would make something like: /foo/1 valid, but /foo?action=1 would be invalid, this would be cool.

Biggest thing would be to make sure order was preserved:

decorators.param("/first", choice=["foo"])
decorators.param("/second", choice=["bar"])

would allow: /foo/bar but not /bar/foo and also work with *args parameter.

When running endpoints from within a docker container for some reason the body portion is being decoded as a bytes-like object b''. The same code running locally works fine. I added a string conversion explicitly to force the body to be a string.

We may want to look into support for the Content-Type header's charset attribute so we are not explicitly attempting to convert a non utf-8 string to utf-8. If that is desired I can put a little more effort into this PR to support that as well. I ran into this issue which prevented me from moving forward. Maybe you have a better approach.

Traceback (most recent call last):
  File "/usr/lib/python3.5/wsgiref/handlers.py", line 137, in run
    self.result = application(self.environ, self.start_response)
  File "/usr/local/lib/python3.5/dist-packages/endpoints/interface/wsgi/__init__.py", line 30, in __call__
    return self.handle_http_response(environ, start_response)
  File "/usr/local/lib/python3.5/dist-packages/endpoints/interface/wsgi/__init__.py", line 33, in handle_http_response
    c = self.create_call(environ)
  File "/usr/local/lib/python3.5/dist-packages/endpoints/interface/__init__.py", line 239, in create_call
    req = request if request else self.create_request(raw_request, **kwargs)
  File "/usr/local/lib/python3.5/dist-packages/endpoints/interface/wsgi/__init__.py", line 77, in create_request
    self.create_request_body(r, raw_request, **kwargs)
  File "/usr/local/lib/python3.5/dist-packages/endpoints/interface/wsgi/__init__.py", line 98, in create_request_body
    body_args, body_kwargs = self.get_request_body_json(body, **kwargs)
  File "/usr/local/lib/python3.5/dist-packages/endpoints/interface/__init__.py", line 182, in get_request_body_json
    b = json.loads(body)
  File "/usr/lib/python3.5/json/__init__.py", line 312, in loads
    s.__class__.__name__))
TypeError: the JSON object must be str, not 'bytes'

Right now, say you had a controller that could have a path:

class Foo(Controller):
    def GET(self, action, **kwargs): pass

where action can be bar or che, so valid requests would be:

• /example.com/foo/bar
• /example.com/foo/che

I'm wondering if we could codify this with camel casing:

class FooBar(Controller):
    """handle /foo/bar"""
    def GET(self, **kwargs): pas

class FooChe(Controller):
    """handle /foo/che"""
    def GET(self, **kwargs): pas

So camel casing class names would move through path bits. This is inspired by some comments Jarid made about us having to set a few params as optional because we had multiple action path bits that needed different attributes:

class Foo(Controller):
    @param(0, choices=["one", "two"], help="the action value")
    @param("bar", default=None, help="only needed if action is 'one' but needs to be optional")
    @param("che", default=None, help="only needed if action is 'two' but needs to be optional")
    def GET(self, action, **kwargs): pass

endpoints dosent start and shows error when tried to start with pm2 in linux I tried following the instructions given here

sudo pm2 start endpoints -- --prefix=index --host=localhost:2002

it would be great to have support for multiple prefixes, so you could have:

app.controllers
package.controllers
package2.controllers

and the router would check all the registered prefixes to find the controller for the request, this would be the first step in supporting plugins. Basically you could have a package that has some built in controllers that you could register in your main app, something like:

from endpoints import register

register("app.controllers")
register("package.controllers")

This would provide flexibility for things like using the package controllers as-is or extending them in your own app, basically if you didn't register them then they wouldn't be used. Likewise the package could register them automatically so just by importing something of the package it could call the endpoints.register thing

the above is all just speculation on my part, I'm not sure how I want to do it yet or what would be the best approach.

So we have an api structure like this we want to support:

/foo/bar
/foo
/

where foo and bar can contain any value (or not be there at all). Currently, we would have one controller that has to handle all three variations:

class Default(Controller):
    def GET(self, *args, **kwargs):
        if len(args) == 2:
            # /foo/bar
        elif len(args) == 1:
            # /foo
        elif len(args) == 0:
            # /

I don't like this because we can't use the decorators to define the boundaries for foo and bar.

I propose we allow a numeric modifier to the class name:

class Default2(Controller):
    # /foo/bar
    def GET(self, foo, bar): pass

class Default1(Controller):
    # /foo
    def GET(self, foo): pass

class Default(Controller):
    # /
    def GET(self): pass

I think this supersedes #56 also, since this will allow us to break up the individual requests enough to use our decorators for each unique request and we can handle what #56 talks about by just adding one more submodule with 2 controller classes, so I think all the bases are covered?

I think this will be a relatively easy (and backwards compatible) change by just having the router check for class_name + len(args) from 1 to len(args) and take the first classname that matches.

Where might this be ambiguous?

If your class name ends with a number:

class Foo2(Controller):
    def GET(self): pass

class Foo(Controller):
    def GET(self, *args): pass

So /foo2 and /foo/1/2 will both go to Foo2.

basically, the decorator should take a ttl and then set the appropriate headers: Cache-Control, Pragma, and Expires.

Likewise, there should be a nocache decorator that makes the page uncacheable:

"Cache-Control": "no-cache, no-store, must-revalidate",
"Pragma": "no-cache", 
"Expires": "0"

right now we don't automatically set the content encoding of the response but we should. I'm thinking it could even be an environment variable if needed

Both the compat module and the _property stuff needs to be switched over fully to using the datatypes versions and then removed from the endpoint's codebase.

Currently, we basically make all the interfaces look a bit like a WSGI request, then http.Request can use .environ and stuff to find information like IP address and host.

I think it would be better to have an InterfaceRequest wrapper that would take the raw request and then the interface could implement the supported methods, and then http.Request would be instantiated like this:

request = Request(InterfaceRequest(raw_request))

I think the class would be something like:

class InterfaceRequest(object):
    def __init__(self, raw_request):
        self.raw = raw_request

    def get_headers(self):
        raise NotImplementedError()

    ...

This was my original note:

create an interface request class that can handle bridging between the interface (uwsgi, asgi) and the request object. So basically, the interface would create an InterfaceRequest class and pass that to Request, then Request would use InterfaceRequest for things like .ip and .scheme

So the big question is, why would we do this over just having these things set directly on http.request in the interface's create_request method like we kind of do now? This solution would make it so the code is run on demand instead of all ran in the create_request method. Likewise, it would provide a standard template for what needs to be implemented, right now to add a new interface I usually look at what a previous interface's create_request method is doing.

Biggest annoyance would be all the tests that just create a request object, I'd need to change all those to take the InterfaceRequest instance, and there are a lot of tests.

Now that python2 support has been dropped I think I will add asyncio support with the ASGI interface. After some tests, it looks like I can have the async and sync interfaces be the same, the sync will just extend the async interface and wrap all the methods, something like:

class AsyncFoo(object):
    async def foo(self, ret_value, sleep=1):
        print("async")
        await asyncio.sleep(sleep)
        print("foo")
        return value


class SyncFoo(AsyncFoo):
    def foo(self, *args, **kwargs):
        return asyncio.run(super().foo(*args, **kwargs))


f = SyncFoo()
print(f.foo(6))

This works in my tests and so, hopefully, something similar to my tests will actually work when implemented so I can keep the interfaces the same and then it's just a choice on what to use.

Links I had open

• Python Asyncio docs
• Asyncio — Moving towards the asynchronous future of Python
• Django async docs
• Reddit Should I stick with asyncio, or return to gevent?
• asyncio_monkey
• SO Asyncio vs. Gevent

Search

• does python asyncio need monkey patching
• python async

Right now, if the body is empty then the it won't log the body at all, it would be better to say something like BODY: <EMPTY> or something like that, so you can see in the logs that endpoints thought the body was empty.

From the docs:

ASGI (Asynchronous Server Gateway Interface) is a spiritual successor to WSGI, intended to provide a standard interface between async-capable Python web servers, frameworks, and applications.

Heard about this from here:

If you are starting a new project, you might benefit from a newer and faster framework based on ASGI instead of WSGI (Flask and Django are WSGI-based).

...Also, if you want to use new technologies like WebSockets it would be easier (and possible) with a newer framework based on ASGI, like FastAPI or Starlette. As the standard ASGI was designed to be able to handle asynchronous code like the one needed for WebSockets.

Check out Starlette, Uvicorn, or FastAPI to see how it is implemented. It looks like FastAPI depends on Starlette, and Starlette is using Anyio as an underlying library. This module: asgiref also looks useful.

The current reference server is Daphne:

The current ASGI reference server, written in Twisted and maintained as part of the Django Channels project. Supports HTTP/1, HTTP/2, and WebSockets.

Found this in some old application code, could probably be moved into Request core:

    def parse_user_agent(self, user_agent):
        """parses any user agent string to the best of its ability and tries not
        to error out"""
        d = {}

        regex = "^([^/]+)" # 1 - get everything to first slash
        regex += "\/" # ignore the slash
        regex += "(\d[\d.]*)" # 2 - capture the numeric version or build
        regex += "\s+\(" # ignore whitespace before parens group
        regex += "([^\)]+)" # 3 - capture the full paren body
        regex += "\)\s*" # ignore the paren and any space if it is there
        regex += "(.*)$" # 4 - everything else (most common in browsers)
        m = re.match(regex, user_agent)
        if m:
            application = m.group(1)
            version = m.group(2)
            system = m.group(3)
            system_bits = re.split("\s*;\s*", system)
            tail = m.group(4)

            # common
            d['client_application'] = application
            d['client_version'] = version
            d['client_device'] = system_bits[0]

            if application.startswith("Mozilla"):
                for browser in ["Chrome", "Safari", "Firefox"]:
                    browser_m = re.search("{}\/(\d[\d.]*)".format(browser), tail)
                    if browser_m:
                        d['client_application'] = browser
                        d['client_version'] = browser_m.group(1)
                        break

        return d

and the test:

    def test_user_agent(self):
        user_agents = [
            (
                "Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.157 Safari/537.36",
                {
                    'client_application': "Chrome",
                    'client_version': "44.0.2403.157",
                    'client_device': "Windows NT 6.3"
                }
            ),
            (
                "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.157 Safari/537.36",
                {
                    'client_application': "Chrome",
                    'client_version': "44.0.2403.157",
                    'client_device': "Macintosh"
                }
            ),
            (
                "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:40.0) Gecko/20100101 Firefox/40.0",
                {
                    'client_application': "Firefox",
                    'client_version': "40.0",
                    'client_device': "Macintosh"
                }
            ),
            (
                "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.12 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.12", # Safari
                {
                    'client_application': "Safari",
                    'client_version': "600.7.12",
                    'client_device': "Macintosh"
                }
            ),
            (
                "curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8x zlib/1.2.5",
                {
                    'client_application': "curl",
                    'client_version': "7.24.0",
                    'client_device': "x86_64-apple-darwin12.0"
                }
            )
        ]

        for user_agent in user_agents:
            d = self.user_agent(user_agent[0])
            self.assertDictContainsSubset(user_agent[1], d)

Body doesn't have the request id:

[I] Request 0c2f934a-f9f5-4ffd-ba6f-4735488587d0 header Accept-Encoding: gzip, deflate, br
[D] BODY: {'foo': 1111}

The request id could probably be shortened to the last part, so 0c2f934a-f9f5-4ffd-ba6f-4735488587d0 would become 4735488587d0

Maybe get rid of the Request part also, so something like:

req4735488587d0

It would be great to have the full request in the summary:

Request 0c2f934a-f9f5-4ffd-ba6f-4735488587d0 response 429 UNKNOWN in 13.3 ms

Could become something like:

Request <REQUEST ID> <HTTP METHOD> <PATH> response <CODE> in <TIME>

so...

Request 4735488587d0 GET /foo/bar response 429 UNKNOWN in 13.3 ms