[erlang-questions] HTTPS and Basic Authentication with Erlang
Thu Feb 16 11:41:43 CET 2017
> 16 февр. 2017 г., в 13:38, Loïc Hoguin <essen@REDACTED> написал(а):
> On 02/16/2017 02:34 AM, Kenneth Lakin wrote:
>> On 02/15/2017 12:37 AM, David Wright wrote:
>>> However I would like to write a restful API and decode the URL and
>> obtain parameters
>>> for the API method.
> Cowboy comes with a REST basic auth example: https://git.ninenines.eu/cowboy.git/tree/examples/rest_basic_auth
>> AFAIK, the "magic" of REST is behaving in a vaguely-standard way to
>> requests containing particular METHODs at particular paths.
> What you describe is *HTTP*.
> The "magic" of REST is to not have to write a client for every single API out there, and instead only write the higher level logic about the media types that are manipulated (which are often standard themselves, for example (X)HTML). The server can then instruct the client what media types are available and what operations you can do with them.
> Browsers are a good example of REST clients. You don't need a separate browser for every single website.
> Most phone apps and "REST API" clients are good examples of non-REST clients. They're written against a specific API and make many out of band assumptions.
> Note that REST is an architectural pattern and doesn't apply only to HTTP, and that HTTP is not enough to have REST: you also need at the very least to have media types that support hyperlinks and forms (or other ways of describing operations on resources).
> Which implies that all APIs that only serve application/json are not REST APIs…
To be fair, you both describe half of REST. Both interlinking *and* good cache/method behaviour (which most browsers don’t rely upon, precisely because WWW is not that RESTful) is required for a REST architecture.
It is also fair to say that most homegrown protocols do not benefit from hyperlinking, and weren’t made with REST in mind (and with vendor mime types) precisely because of that.
More information about the erlang-questions