Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add _method into a request payload on HTTP transport #285

Open
dahlia opened this issue Jun 9, 2018 · 0 comments
Open

Add _method into a request payload on HTTP transport #285

dahlia opened this issue Jun 9, 2018 · 0 comments
Labels
cmp:transport Component: Transports typ:discuss Type: Discussion

Comments

@dahlia
Copy link
Member

dahlia commented Jun 9, 2018

On the current HTTP transport, a request to call a method consists of two components (apart from @http-resource annotations):

  • a method= parameter in a query string which contains a behind name to resolve a method, and
  • a JSON object consists of method arguments in a request content (hence Content-Type: application/json).

Separating a method name from method arguments has an upside which we've intended: method names can be easily captured without configuration by several HTTP loggers and monitoring tools, because they are a part of a URI.

On the other hand, it means a method call is represented by two components together, or an HTTP request. A whole HTTP message tends to lengthen, and its representation is not deterministic to its meaning. It even is hard to normalize; see also AWS's rule to normalize an HTTP request to sign. It's subtle downside in theory, but in practice, it makes things like signing or encryption hard to implement.

So, here I propose to add a "_method" field to represent method's behind name to call into a JSON object in an HTTP request content. It turns only a JSON object into possible to be a single atomic component to represent a method call. We only need to sign or encrypt only a JSON object, not a whole HTTP request. We don't have to normalize the order and casing of headers either.

If we promote this proposal we could make nirum-python-wsgi to accept both forms for the time being and remove the older one later, or leave both forms as equally legal.

@dahlia dahlia added cmp:transport Component: Transports typ:discuss Type: Discussion labels Jun 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cmp:transport Component: Transports typ:discuss Type: Discussion
Projects
None yet
Development

No branches or pull requests

1 participant