As contemporary application developers and architects, we all feel overwhelmed with all the new 'stuffs' that are throwing at us - the new frameworks, the new 'standards', the new 'thoughts', and the new 'ways' of doing things.
However, application developers and architects are not in the fashion business, we do not, and, should not, blindly adopt all the new stuffs. The logical approach is what we should do.
For example, there was this new XHTML 'standard', and, there were many books and hypes following it. However, in the end, the XHTML is pretty much dead. The lesson learned is that new 'stuffs' must pass practical tests. Just be new and labeled 'standard' does not cut it.
In the world of application development, there are many 'standards' that are basically doing the same thing. For example, the JSON and YAML are basically doing the same thing. Adopting one or the other would not really a matter of live or death. As to the case of XHTML and HTML5, the situation is a bit different. The limitation and feature matters - if you follow one, you may not get the feature or benefit of the other. For both cases above, these are physical limitations. Once you adopted, you take what is come with it.
New thoughts or practices, on the other hand, are not one or nothing. People do not have to adopt the whole thing to take advantage of them. The RESTful API, as was defined by Roy Fielding in his 2000 PhD dissertation is a good example.
The trend of thoughts of the RESTful API is heavily trending on the HTTP protocol. The 'standard/practices' try to use/adopt/fit the use of HTTP's features, where the idea of stateless is not necessary new, but is an emphasized feature. The idea of API or 'Client-Server' architect isn't new either. It actually existed for a long time. Even the use of plain text as the communication medium is an old practice. However, the increasing processing power and network bandwidth made the practice much feasible.
The RESTful API had been new and trended for a while. However, as of this writing, along with my previous article REST or Representational state transfer, we have seen deviant from the practice of the REST API. For example, the Graph API and GraphQL API.
Personally, from the philosophic point of views, I really am questioning REST's strong adoption of the HTTP protocol. For one, the HTTP was not designed to facilitate the 'Client-Serve' application architect to begin with. Second, the 'cast' to follow GET/PUT/POST/DELETE keyword's original purpose is just so artificial and does not gear toward improving 'Client-Server' architecture. The use of GET with query string is an obvious example - see the next paragraph.
As of today, the object oriented programming is largely the accepted best practice. The basic practice of object oriented programming is to group related data into an object instead of treat them as individual data items. Of course, for complex objects, objects can be nested, and the data are, therefore, nested too. The HTTP GET query string, by its design, there is no nested or structured data. By requiring transferring data with query string, the sending and receiving ends are forced to unpack and repack the data to facilitate the object oriented practice, while the POST keyword can easily send structured objects via JSON or other means.
As mentioned earlier, the REST API is a practice, and there really isn't the need to adopt it in full in order to take the advantage of it.
The doctrine of using GET/POST/PUT/DELETE keywords also does not make sense in that it limited the possible operations to create, read, update and delete - aka CRUD. However, as we all know, there are many operations that are required to build an effective Client-Server applications. With REST API, it is a common practice to pass parameters/flags to fine tune the desired operations and the adoption of the doctrine of GET/POST/PUT/DELETE forced the application to check for desired operations in two places: once in the HTTP keyword (even though this may be handled by, say, the .NET web API framework) and once in the parameters/flags passed in. This may not be a big deal. But the question is why, when we can pack all the info in just one parameter/place. Also please note that the end-point syntax standardization is not tied to the doctrine of GET/POST/PUT/DELETE and you can simply use the POST keyword while keeping the same end-point syntax.
The design of the end-point also worth noting. I have saw very typical design that mimic the design of database table. Personally, I have strong doubts about this approach even though I understand the influences from the RESTful doctrine. This approach, in essence, is asking the client application to perform the work of a database. It is true, this approach will guarantee the accessibility of all data. However, from application's point of view, this is never the aim of an application architect. The aim of an architect can be the decoupling, the layered design, shield higher layer from the complexity of the lower layer ... etc. But, not the access to the every single detail of the lower layer. This approach of asking clients to know and handle the database table directly, actually, violates many application design's best practice. For one, you are not decoupling the design and did not isolate the higher layer from the lower detail unless you build all these layers into the client application. Let's forget about the performance for a moment. Just think about what if you decide to change the database table design. Without changing the end-point design, do you still guaranteed the access to all the details? Also, obviously, the black box approach of an object oriented design is violated. The design also force the API consumer to learn all the relations between entities/objects. Also, the performance is going to take a hit. Just imaging if you need to join two tables. All the records will have to be read from the server and check for the matches before presenting the matched info to the user.
People working in the IT field are constantly overwhelmed by new stuffs and it is my hope that, with this article, people that working in the IT field will actually look at the new stuffs and make logical decisions.
