3 ms·

> But why is it important at all? Because that approach fits the problem of implementing a request/response message pattern to a tee. > Why don’t we see numer

> But why is it important at all? Because that approach fits the problem of implementing a request/response message pattern to a tee. > Why don’t we see numerous both-side frameworks which make http (rest, ws, etc) completely transparent? Because you'd be making the mistake of mixing up how to handle your messages with how you parse and interpret the messaging protocol. You should not be mixing up responsibilities which are entirely orthogonal. You either parse HTTP requests to decide how their messages should be interpreted (i.e., routing) or you act on the message that has been correctly routed (i.e., what you actually wanted to do in the first place ). Do keep in mind that HTTP just serves as a messaging protocol, and in order to deliver a message first you need to validate it and pick where and how it should be handled. Web APIs are designed arbitrarily to depend on some features of HTTP to validate and route messages, and some of these design decisions are so common that some web framework make developers' lives easier by providing built-in modules that avoid boilerplate code (i.e., middleware). If you're developing a web API and you are systematically having to deal with HTTP then, to put it bluntly, you are doing it wrong. That job is already done if you pick one of these frameworks, and you're simply reinventing the wheel with no good reason. > Instead we happily define routes in yet another way, which feels like when I was in a school writing masm 100-liners to open a file and print its contents. Am I missing something? Yes, the fact that with these frameworks you are able to focus on implementing what you're supposed to be implementing (essentially message handlers) instead of having to waste your time reinventing the wheel filling in boilerplate code just to get to your task at hand.

wruza 7y ago
What are frameworks/middleware you’ve mentioned? I’m confused since if the snippets above reinvent some wheel, I would like to use that wheel instead. The other commenter suggested looking at Phoenix/Elixir, but its getting started doc doesn’t seem to do net-transparent objects - it’s the same “hey route, hey handler” approach. My idea is that if you do e.g. a taxi app, then the only ‘routes’ you should care about are routes on the map.
- rumanator 7y ago
  > My idea is that if you do e.g. a taxi app, then the only ‘routes’ you should care about are routes on the map. There are no routes on the map. As a backend developer, your job is to define what are the valid routes and how to handle non-compliance but valid requests. Take for example content negotiation. Do you honour the Accept header or do you serve content based on the request path, such as the resource extension? What should you do if you receive a request where both approaches are used but in a contradicting manner? Now, keep in mind that API versioning is handled as content negotiation. Now, let's add auth to the mix. Do you intend to hand-roll a few OpenId connect workflows by hand, which involve 3 or 4 HTTP requests behind exchange between 2 or 3 actors? Are you intending to hand-roll token expiration checks? Or do you prefer to use an API key or session cookies, or any other, or a mix of all of them put together? And what about caching? Are you expecting to check and tweak cache control and etags headers each and every time you receive a request? Or do you only want to receive a request and act upon it's request body? If you use one of these web frameworks, all you need to do is configure your middleware to specify how you handle auth and cache and content negotiation, define routes based on the outcome of your content negotiation process, and proceed to implement your web API.
- marmaduke 7y ago
  The answer to your implicit question IMO is that routing is hard abstract away, universally. For every approach to do it, there will be detractors claiming its not good enough. So à library author gets traction by leaving the bike shed plumbing to the API user.

wruza 7y ago

What are frameworks/middleware you’ve mentioned? I’m confused since if the snippets above reinvent some wheel, I would like to use that wheel instead. The other commenter suggested looking at Phoenix/Elixir, but its getting started doc doesn’t seem to do net-transparent objects - it’s the same “hey route, hey handler” approach. My idea is that if you do e.g. a taxi app, then the only ‘routes’ you should care about are routes on the map.

rumanator 7y ago
> My idea is that if you do e.g. a taxi app, then the only ‘routes’ you should care about are routes on the map. There are no routes on the map. As a backend developer, your job is to define what are the valid routes and how to handle non-compliance but valid requests. Take for example content negotiation. Do you honour the Accept header or do you serve content based on the request path, such as the resource extension? What should you do if you receive a request where both approaches are used but in a contradicting manner? Now, keep in mind that API versioning is handled as content negotiation. Now, let's add auth to the mix. Do you intend to hand-roll a few OpenId connect workflows by hand, which involve 3 or 4 HTTP requests behind exchange between 2 or 3 actors? Are you intending to hand-roll token expiration checks? Or do you prefer to use an API key or session cookies, or any other, or a mix of all of them put together? And what about caching? Are you expecting to check and tweak cache control and etags headers each and every time you receive a request? Or do you only want to receive a request and act upon it's request body? If you use one of these web frameworks, all you need to do is configure your middleware to specify how you handle auth and cache and content negotiation, define routes based on the outcome of your content negotiation process, and proceed to implement your web API.
marmaduke 7y ago
The answer to your implicit question IMO is that routing is hard abstract away, universally. For every approach to do it, there will be detractors claiming its not good enough. So à library author gets traction by leaving the bike shed plumbing to the API user.