Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 months ago.
Improve this question
I'm currently developing a micro service that basically provides calculation services to other micro services. It does not store data or have any resources like a sales order. It only calls other micro services and then calculates metrics and prices to return a result.
I'm kind of struggling trying to make a rest API with resources names that are nouns when all I do is calculate stuff and return results (more like an action).
So can we have a micro services that behaves more like an HTTP API than a Restful service (is it a bad practice, an anti pattern , an architecture smell, ....)
Regards
You can use whatever you want and in your particular case I am pretty sure you won't see any drawbacks. From my point of view only difference with rest is mostly semantic -some people may also argue about cacheability but I don't think so-
Apart from rest/rpc creating microservices without any actual domain could cause a maintenance issue in the long run as you totally depend on some other microservices data whenever a change required in their side you may also need change this microservice. That is why I don't recommend those kind of calculation services unless you have a valid scalability requirement.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
In our company 2 development teams:
Web team developing online store
java team developing CRM application
Online store send REST requests to CRM. And Java team lead asked web team lead to restrict RPS from online store to CRM, because CRM receive too many requests and periodically goes down. The web team doesn't like it, they think that it is CRM side issue.
What is best practice for this kind of situation?
Can you provide me reference to some authoritative knowledge base?
Thank you.
There is no best practice for that kind of situation because everything depends on specific circumstances. If the store generates more requests than it is necessary, it should be reduced. If the CRM app cannot handle the required number of requests, it should be optimized (or resources increased). You provided too few details to give you a clear answer.
From the technical side, I can only give you 2 overall suggestions:
If query requests (GET) cause the problem, you should think of a better data caching on the store side to reduce the number of requests.
If command requests (POST, PUT etc.) cause the problem, you may consider how many of your requests have to be handled synchronously. Maybe queuing commands instead of processing them right away would help you to better utilize resources of the CRM app and reduce downtime.
I highly doubt if anyone will be able to give you a more concrete answer basing on so limited data.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
What does a true REST architecture looks like ? I mean from a developers perspective what can be done in order to have a true REST Architecture.
So I've read some articles and according to this one link,
there are 4 levels. Well WebApi provides you with the minimum in order to have REST (URI + HTTP verbs). What about The 4th HATEOAS? How would one implement this level, what are some good practices, why is it good to have it?
Are there any other things that a good REST Architecture should have?
What does a true REST architecture looks like ?
A true REST architecture looks like the world wide web.
The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web -- Fielding, 2000.
Generic browser communicating with generic servers, using standardized messages and media types.
There's no particular reason that I should be able to use the same client to answer questions on stack overflow that I use to watch funny cat videos, and no particular reason that I should be able to use that same client to search for videos, or shop for books, play chess, read the news, etc.
Are there any other things that a good REST Architecture should have?
Hypermedia. The "HTML" part of the Richardson Maturity Model, and the key element of "hypedmedia as the engine of application state".
The ability to communicate to the client "there is another resource over there, and it understands these standard messages" is a really big deal.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Assume I have separated my monolithic application into 5 microservices.
Now do I need to run these 5 microservices in 5 processes or is it OK to have all 5 of them run in a single process? Why?
The very purpose of choosing to go with Microservice Architecture is to achieve scalability and agility through independence of services. Here is an excerpt from a good article on the matter, you might find interesting. It is by a pretty credible source - SmartBear (the creators of SOAPUI):
While there is no standard, formal definition of microservices, there
are certain characteristics that help us identify the style.
Essentially, microservice architecture is a method of developing
software applications as a suite of independently deployable, small,
modular services in which each service runs a unique process and
communicates through a well-defined, lightweight mechanism to serve a
business goal.
So yes, you should absolutely go for deployment as separate processes. You will be much more flexible this way. For example, running all 5 services in a single process could make it impossible to hot-swap new versions of single microservices without stopping all the others (even though they might not be logical interdependence between all services).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Did someone try developing a GraphQL instead of RESTful API? Can someone give real life (not only theoretical) pros and cons. Basically from my research I found that the GraphQL power is to get exactly what you need nothing more. Where with REST APIs, you often have to make a series of requests and you can easily get back more information than you really needed.
Is it worth the time spent on researching and learning GraphQL? Any bugs or showstoppers that get your attention?
This question is primarily opinion-based.
But from my experience:
Multiple requests on a RESTful-API for just one thing often indicates a lack in the API design, namely the needed resource was not available and therefore stuff needs to be gathered from different resources to compensate for this.
A REST-API that could be easily replaced by GraphQL indicates, that the API was in fact a CRUD-HTTP-API, what is considered an Anti-Pattern among REST-Evangelists.
Also worth noting is, that GraphQL puts responsibilty on the client, because the backing API is reduced to be a datastore that just needs to be queried. REST on the other hand enforces the behaviour of the client and therefore reduces responsibility on it. The client gets reduced to be something similar to a browser.
There are cases the one or the other approach would yield better results, but that greatly depends on your situation.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I would like to have a URI like this /car/toyota, however I don't want the car resource to map to a database table for example. Instead I would like car to just be resource that is used for information retrieval only (ie. no POST, PUT, or DELETE on it), and /car/toyota/ would retrieve that data somewhere else, say through another REST API on another web server that provides this information.
Is this good design?
This probably belongs on something more like https://softwareengineering.stackexchange.com/
That said, this question depends entirely on the infrastructure of the environment you're making your REST requests on. If you have the ability to control the REST API on the web server providing the information, there's really no reason to wrap that API in another API. All of the call forwarding and potential necessity to translate from one request format to another really just adds un-necessary overhead.
That said, if you're accessing an API that you have no ability to re-format, or if you're accessing an API that you don't want client servers talking to directly, then there's a potential design perk for wrapping a different REST API in your own read only API.
Unfortunately, without having a clear picture of the entire architecture and the problem you're trying to solve, it's pretty difficult to decide if a wrapped API is a good design or not. My only advice is the preferred approach would be to edit the existing API if you can, but that isn't always practical.