REST and GRAPHQL
REST and GRAPHQL
https: //github.com/Morr0/Railway-Rest-Graphql Talk about client and server ### The REST route: The school of thought here revolves around resources. Each resource has actions. Those resource and action combination together produce endpoints with different behaviours. Without going too philosophical. A train is a resource, having actions, those actions are **get all trains**, **get a specific train**, **add train**, **remove train**, **decommission a train** and so on. The general idea each one of those actions is a separate entity that is consumed by a client. For example, I can hit (call) the **get all trains** endpoint with a `GET` method to get all trains. I need to consult the documentation of the endpoint but this is self-explanatory. Similarly let's say I want to decommission a train and call it's endpoint with a `GET` method, this would work if it was programmed so but as a developer of an API it should have either a `POST` or `PATCH` method. Those methods I am talking about are [HTTP Methods ](https: //developer.mozilla.org/en-US/docs/Web/HTTP/Methods). Since the Web runs on HTTP. The RESTful architecture assumed API actions would use them. Even though HTTP and REST are not the same thing, they have coupling in terms of keywords. Don't get me wrong, you can design and implement a RESTful API completely on a protocol other than HTTP but why bother when browsers support it and is what retrieved the article you are reading now. Ok let's continue, imagine now I have other resources, such as a train station resource, with it I can know about a specific train station platform, overall about the station, cause the station to stop having trains stop. With an API I design I provide a full interface to the client, now obviously the client must be authorized to use certain endpoints. Let's add more resources, such as rail track, rail traffic, train electricity resources and so on. Now I ended up with a lot of things. Nothing wrong yet, complexity grows with the system and that is usual behaviour. The problem I may face here for example, I want to know the state of the traffic light a kilometre front of Y station for a train parked at the station that is late. In essence, the train needs to hurry fast and wants to know whether he can speed up until the next traffic light. Ok let's address it. First I need all the information to make a decision of whether the train can speed up or move normally so let's fetch the following endpoints: - /station/Y/platform/{specific platform } - /traffic/light/{id of traffic light for station } - /traffic/light/{id of traffic light ahead of station } - /train/{id of train } Here I called 3 distinct endpoints, I got information about the platform to know what train is late, then I asked about the traffic light right outside the station and the one further and then got more information about the train. In total 4 calls. Now I can make a decision and call the appropriate endpoints to move or let the train wait maybe there is a freight train in front that is slow. This is a way of designing a RESTful API, it is the standard best practice to do it this way. Separation of concerns is key because of serveral reasons, maybe the 'traffic' resource is ran using a C# backend while the others on Java. The use of REST allows the use of any backend language since communication is done in HTTP (99% of the time) with JSON as the information format. You could have had one endpoint of course to fetch all the required information and one for the decision however here the load will be on the server and is not a good practice to do many different things in one call. It usually causes dependency issues on other services and does not promote a separation of concerns. Now imagine there is a train race, it is train olympics and 4 trains are competing and over 10 million viewers are simulatenuosly viewing. The pressure will be huge on the backend, since each viewer maybe viewing info on each train to maybe bet on it, seeing what tracks have less curvature, which stations allow trains to move easily through them and anything... In this case, each endpoint that gets hit maybe returning plenty of information, most of which maybe unnecessary. This results in heavy JSON loads transferred and also poor user experience where clicking on a different