Defining extra HTTP methods

[binarytrails]

Hi devs!

Is it possible to define extra HTTP methods even if in their definition it states that its their mapping to nodejs ones? What is this relationship? Basically, we need to use ENCRYPT, SIGN, etc. Currently, I wrote a RESTful oriented ones like /:resource/verb but it would break the current RESTful API which we don't want to. I want to find the right way to do it. I could always make a PR if necessary!

Thank you for your time! Seva

[eao197]

It's not an easy question.

Can you provide the list of methods you need?

[binarytrails]

@eao197 LISTEN, STATS, SIGN, ENCRYPT those are the only ones I saw in our API that are not already defined in the http_method_t like SUBSCRIBE,UNSUBSCRIBE.

Thank you so much!

[eao197]

I've got your point. As I can see the usage of non-standard HTTP-method is not widespread, but it is not uncommon too. So it will be good to have the ability to handle non-standard HTTP-methods in RESTinio.

But I don't like the idea of integrating all non-standard methods into RESTinio's implementation. I think there should be a way to allow a user to extend the list of HTTP-method by himself/herself without modifying RESTinio's code.

We'll discuss that issue inside our team and reply to you ASAP.

[binarytrails]

@eao197 Perfect, I'll be waiting. I agree that they are not standard HTTP methods but the aim is to keep the new RESTful API backward compatible. Tell me if there is anything I can do.

[eao197]

We've done some discussion, and it seems that there is no simple way to add support for custom HTTP-method to RESTinio. There is a need for some experiments. But we'll have no time for that in the several next days because we're now busy with rolling out a new release of another our project. So I hope we can return to that issue at the end of the week.

[binarytrails]

@eao197 if you can suggest me ways of trying to implement it following RESTinio design, I can make a PR! Otherwise, looking forward to your experiments! I would say the backward compatibility of our proxies is the only critical thing due to their omnipresent usage in the jami.net project. Cheers,,

[eao197]

@binarytrails We have discussed this issue and the only solution we have found so far is:

• you need a customized version of http-parser with support of your custom HTTP methods. It is necessary because HTTP is processed by http-parser library, not by RESTinio. And http-parser just rejects all unknown HTTP methods. It means that you need a fork of http-parser with hardcoded new HTTP methods inside. It is not a complex task. This is my example of such fork;
• we can add a customization point to RESTinio. That point will allow using RESTinio with a customized version of http-parser. I've done a draft of that version of RESTinio. It can be found here (in 0.4.10-custom-methods-example branch). And here you can download a tarball with this draft and related libraries inside;
• customization of RESTinio for non-standard version of http-parser can look like in that example. Note fragments between lines 25-32, 35-66 and 141-146.

Maybe there are some other approaches to support custom HTTP-methods in RESTinio, but we don't discover them yet.

So if that approach is appropriate for you then we can go further and start working on the preparation of next release of RESTinio with ability to work with custom versions of http-parser. But note that support of those custom versions of http-parser is your responsibility, we won't support them (and my custom version of http-parser is just an experimental example).

[binarytrails]

@eao197

I went through the nodejs/http_parser fork, RESTinio custom_http_methods example and it looks absolutely great!

We really appreciate the efforts that your team made for the backward compatibility of our non-standard HTTP methods. Let's move forward and have it at the next RESTinio release.

I will embbed and test a forked http_parser with the RESTinio integration into the OpenDHT PR 403 asap.

Sincerely, Seva

[eao197]

@binarytrails

We decided not to keep compatibility with restinio-0.4 because even with some tricks new definitions of http_method_t::http_get, http_method_t::http_put and so on won't be complete replacement for the old ones. Because of that we started restinio-0.5 where there is no http_method_t at all. Instead there is http_method_id_t class. There are also old http_method_get(), http_method_put(), http_method_post() and other functions those return instances of http_method_id_t.

In restinio-0.5 the example of custom HTTP method support will look like that. Please note the following changes:

• an instance of http_method_id_t requires an integer ID of HTTP method and a pointer to string name of the method (that pointer should outlive the http_method_id_t instance);
• only one from_nodejs method should be defined in custom_http_methods_t;
• name http_methods_mapper_t should be used in traits_t.

The second beta version of restinio-0.5 is available from GitHub or new restinio repository on BitBucket. You can try it, it seems to be almost ready to be released as a stable version 0.5.0. We have to update restinio's documentation so the official release is expected on next week. But you can use restinio-0.5 right now.

[binarytrails]

@eao197

Seems very reasonable besides, it is not a big change in the code; I really like your example on the Custom HTTP methods.

Thank you for your work!

Sincerely, Seva