I tried to take a more detailed look at REST - Spring seems to love it so much, and I am confused. REST is fine for basic CRUD operations on "resources", but it seems awkward for applications which need to keep state, such as workflow applications. I read in one of the answers on SO, can't find it now, that the state should be kept on the client. This seems strange: what prevents then the client from cooking up a request, claiming he is in a state which he is not in? A way around this could be that the server sends to the client his next state signed, and the client then uses this signed state on his next request to the server. If anyone has seen a "RESTful workflow application", is this how things actually get done?
REST = Representational STATE Transfer. Client and server exchange the state of a resource. So basically it's kept on the server and updated (/created/deleted) by the client.
REST isn't awkward at all for workflow applications, however you may define that. The most difficult part when designing REST applications is designing the representations and most of all the resources. A resource isn't merely an entity from the database.
As #NeilMcGuigan has mentioned, the RestBucks sample application deals with workflows. There's a video on the SpringSourceDev Channel on YouTube, where Oliver Gierke presents the application.
Related
I'm starting to work with NestJS, a Javascript framework for building RESTful api's.
The framework encourages you to work with multilayered architecture, separating controllers, services and repositories.
In this project of mine, I have a RESTful api that talks to my website, and I'm currently in the need of using websockets for several reasons.
The general behavior of a module that will use the websocket protocol (in my app) is:
client makes http request with a message -> backend validates -> backend broadcasts the message through websockets.
Much like a chat application.
The problem is that I'm having a hard time figuring out where is the best place to put these broadcast calls. It seems like every layer is the wrong place.
I won't even consider the repository layer. Talking strictly about whether should I choose the controller or the service, they both seem wrong.
I don't want to send websocket messages in the same place where I handle HTTP requests, and I sure don't want to send them in the same place were I deal with business rules.
I've come to an approach, but I'm not sure if it's necessary to do it. I'm using Redis as caching mechanism, and as a store to Socket.io, so that I can horizontally scale my app and consistently send broadcast messages through sockets. Redis also has a Pub/Sub feature within it, and an awesome notification system called "keyspace notifications" that will publish messages to channels depending on the action performed in the cache memory store. Long story short, HTTP requests changes resources in the backend, these changes are reflected in my Redis cache and, with a (to-be) well crafted key design system, I can listen to the modifications in the cache from another, separate, module and fire the necessary broadcasts.
An illustration of the structure:
Actually, using the correct keywords I found this article in which the author is doing something similar to what I'm proposing here.
I'm trying to start a little microservice application, but I'm a little bit stuck on some technicalities.
I'm trying to build an issue tracker application as an example.
It has 2 database tables, issues and comments. These will also be separate microservices, for the sake of the example.
It has to be a separate API that can be consumed by multiple types of clients e.g. mobile, web etc..
When using a monolitic approach, all the codebase is coupled together, and when making a request to let's say the REST API, I would handle for example the '/issues/19' request
to fetch the issue with the id '19' and it's corresponding comments by means of the following pseudocode.
on_request_issue(id) # handler for the route '/issues/<id>'
issue = IssuesModel.findById(id)
issue.comments = CommentsModel.findByIssueId(id)
return issue
But I'm not sure on how I should approach this with microservices. Let's say that we have microservice-issues and microservice-comments.
I could either let the client send a request to both '/issues/19' and '/comments/byissueid/19'. But that doesn't work nice in my point of view, since if we're having multiple things
we're sending alot of requests for one page.
I could also make a request to the microservice-issues and in that one also make a request to the microservice-comments, but that looks even worse to me than the above, since from what
I've read microservices should not be coupled, and this couples them pretty hard.
So then I read about API gateways, that they could/should receive a request and fan out to the other microservices but then I couldn't really figure out how to use an API gateway. Should
I write code in there for example to catch the '/issues/19' request, then fan out to both the microservice-issues and microservice-commetns, assemble the stuff and return it?
In that case, I'm feeling I'm doing the work double, won't the API gateway become a new monolith then?
Thank you for your time
API gateway sounds like what you need.
If you'll keep it simple, just to trigger internal API, it will not become your new monolith.
It will allow you do even better processing when your application grows with new microservices, or when you have to support different clients (browser, mobile apps, watch, IOT, etc)
BTW, the example you show sounds like a good exercise, in reality, for most webapps, it looks like over design. I would not break every DB call to its own microservices.
One of the motivations for breaking something to small(er) services is service autonomy, in this case the question is, when the comments service is down should you display the issue or not- if they are always coupled anyway, they probably shouldn't reside in two services, if they aren't then making two calls will let you get this decoupling
That said, you may still need an API Gateway to solve CORS issues with your client
Lastly, comments/byissueid is not a good REST interface the issueId should be a parameter /comments/?issueId=..
I need to send an information to a user via a web-api only once by session, and I used to do in asmx by storing a variable in the session.
As in web-api I can't use sessions, how can I do this ?
Started as a comment, but ended up being too long...
ASP.NET Web API is mainly used to create HTTP services and, as Microsoft claim, ASP.NET Web API is an ideal platform for building RESTful applications on the .NET Framework. Such services are meant to be stateless so what you're trying to do is technically going against a pretty fundamental design goal. Having said that, things are not as clear-cut as they seem and there's some (almost religious) debate over whether a REST service should be stateless or allow state in some degree.
The following SO questions might give you some help and/or direction about achieving what you want:
ASP.NET Web API session or something?
If REST applications are supposed to be stateless, how do you manage sessions?
How to manage state in REST
Also, the following StrathWeb article gives some additional advice (with a code example) and links to other sources of information:
http://www.strathweb.com/2012/11/adding-session-support-to-asp-net-web-api/
In a project I'm currently working on, I'm having to store some state information for token-based user authentication and, since I have access to a database, I use a table to store the information I need. Technically speaking, and certainly for some people, I'm breaking the rules. But it works for me and, at the end of the day, you have a job to do and you may not always have the time to do things 100% correctly, so you have to be pragmatic in your approach.
I admit I am not wholly familiar with the .net webapi, but I have just been handed a project that a previous developer started and explained prior to his leaving that using the webapi services that we could instantiate a service that would continually compare file data with database data if one was newer than the other it would update either the database or the file. The trick is that their is a old PowerBuilder Com piece that extracts or compresses depending on whether it is going to the database or visa versa.
Additionally there will be real time requests for files (data) which will require those requests to be elevated in the process for being sent to the Com object as it were.
With this rather lengthy concept laid out, can a webapi service actually run as a continuous service as described? My understanding was or is that it cannot, and that a different service approach would be required using the webapi to manage the queues and messages for real time requests. Am I missing something here?
Thanks in advance.
Russ
WebApi is not a platform for continuous services. Its purpose is just to provide an interface to your application over HTTP.
In this scenario, WebApi would only be useful in its ability to accept requests. The data in the request can then be used to query your long running internal systems for data, or to update or create new data. WebApi embraces the HTTP verbs (GET, POST etc) for this exact purpose, making HTTP the protocol of your application's state.
Also, with regard to returning data. WebApi simplifies the serialization of a complex object into javascript (by default, overridable if need be). This is useful when your Api is consumed by clients speaking json.
This is more a theoretical question than a practical one, but given I undestand the principles of SOA I am still a bit unsure about if this can be applied to any app.
The usual example is where a client wants to know something from a server thus we implement a service that can provide that information given a client request, it can be stateless or statefull, etc.
But what happens when we want to be notified when something happens on the server, maybe we call a service to register a search and want to be notified when a new item arrives to the server that matches or search.
Of course that can be implemented using polling and leverage that using long timeouts, but I can not see a way in the usual protocols to receive events from the server without making a call to ask.
If you can point me to an example, or tell me an architecture that could support then you have made my day.
Have you considered pub-sub (ie; WS-Eventing, WS-Notification)? These are the usual means to pushing "stuff" to interested consumers/subscribers.
You want to use a Publish-Subscribe design. If you are using WCF checkout Programming WCF by Juval Lowery. In the appdendix he shows how to build a Pub-Sub system that is actually fully Per-Call. It doesn't even rely on CallbackContracts and keeping long running Channels open and so doesn't require any reconnection logic when communication is broken...let alone the need for any polling.