Menu
REST APIs are always considered as infrastructural purposes. I am not an expert, but I caught that the principles they should implement deal with horizontal scaling and performance. They are supposed to suppress all kinds of affinities between clients and services (no session, etc...). REST APIs are rarely considered from a business perspective.
Last week, someone in the team proposed to implement a part of a legacy application as a REST API. This application was previously embedded as a library (.NET) in every application that requested it. The REST API quickly suffered from performance issues (too many round trips between the client and the server). As a workaround, caching was implemented (on the server side). In my opinion, it violates the REST principles. Without caching, we should have many servers for one client for acceptable performance, with parallel requests or a load-balancer (or something like that...).
As we speak about APIs, I suppose such APIs should be driven by business needs. Based on your experience, are there business use-cases that are not suitable with REST ?
[EDIT] The API is about simulating a workflow from entries coming from the client...
320
One of the disadvantages of RESTful APIs is that you can lose the ability to maintain state in REST, such as within sessions. It can also be more difficult for newer developers to use. It's important to understand what makes a REST API RESTful, and why these constraints exist before building your API.
The REST API will be alive for many years to come because many companies set up integrations and forget about them until there's a problem. It is still one of the dominant types of application integrations: REST API, SOAP, and more recently GraphQL. For those not, aware, REST is a type of API design pattern.
The HATEOAS constraint is an essential part of the "uniform interface" feature of REST, as defined in Roy Fielding's doctoral dissertation. Fielding has further described the concept on his blog.
As a workaround, caching was implemented (on the server side). In my opinion, it violates the REST principles.
Actually using cache is a REST constraint which you MUST follow. Fielding dissertation 5.1.4 Cache: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_4 I suggest you to read the whole dissertation (or at least the REST part) before any further questions.
they are supposed to suppress all kinds of affinities between clients and services (no session, etc...).
Statelessness is about moving the session to the REST client, not that you cannot have a session. You don't want to maintain that many client session on the server side, if you can do it on the client side. This makes caching easier.
REST APIs are rarely considered from a business perspective.
I assume that's why most of the big companies have REST APIs. E.g. facebook, google, twitter, etc... These APIs are mostly for 3rd party clients. Ofc. if your API will be consumed by many clients in the company then using REST can be an alternative to using SOA, other RPC or maybe message broker solutions.
Last week, someone in the team proposed to implement a part of a legacy application as a REST API. This application was previously embedded as a library (.NET) in every application that requested it.
REST is about building an application interface (or delivery method) which the clients can use, and it is not about building applications. It's purpose is similar to the purpose of SOA and the other things I previously mentioned. DDD is about building (big) applications.
The REST API quickly suffered from performance issues (too many round trips between the client and the server). As a workaround, caching was implemented (on the server side).
In such a situation it can be rewarding to examine the cause of the performance issues. If you send a series of messages, because the REST API lacks a feature, then it is good to implement the feature in the REST service or if it is something complicated, which does not necessary belong to a low level service, then you can write an upper level REST service, which consumes the low level service (aka. layered system constraint). If the problem is the too many users, then ofc. caching and horizontal/vertical scaling is the solution.
When not to use REST APIs?
I don't think there is such a rule. You can use REST on any places where you would use SOA or any request-response based messaging solution. I don't think it is an ideal fit for event based messaging, so the technique has it's limitations. You can make a workaround with polling or server sent events in such cases, or you can create a mixed interface which uses both REST via HTTP for the req-rep pat and (web)sockets for the event based part of the application interface.
REST is an ideal choice in situations, when you don't want to spend money on writing different clients for your users or you want an interface which the client developers can use to integrate with your system. E.g. public facebook api, which can be used by fb app developers or private api of a wholesaler, which can be used by the webshops of the retailers to automatically change the prices or order products to fill the inventory.
By single HTML page web applications REST can be good to prevent the duplication of the server side code on the clients. E.g. building request templates (URLs, forms, etc...) is moved to the service (aka. HATEOAS constraint). So a client running in the browser, can use some general code to build the complete HTML page based on for example a JSON-LD response. This is not frequently used currently.
66
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
