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.
Related
I am Spring Boot dev.
I develop RESTful web services.
One of my colleagues developed an API and it does two things on the basis of operation type.
If opType = Set, the api sets/unsets a flag at the backend and if opType = Get, the api gets the status of the flag.
Does this not break the architecture of REST APIs?
We have Post/Put to change some data at backend, either create or update.
And we have Get, to get the status of some thing from backend.
Now, I want to opinion of better developers!
Should this be allowed, like having multiples operations with one API call, or should we create multiple apis for each of the tasks.
Also, the front end devs in my team, don’t like integrating multiple apis somehow, suggesting that more the api calls, poorer user experience, customer will have.
Is this the normal practice among app developers?
Comments requested.
GET requests in REST are not supposed to change the state of the server, these are read operations, whereas PUT/POST do modifications to the state of the server in the most general sense.
So usually you should have two endpoints GET to read the state of the flag and put/post for creating and modifying the state.
Having said that there is nothing that can technically restrict you from implementing everything in one API, such an API won't adhere to REST conventions, that's true, but from the client-server communication standpoint (HTTP based usually), it's still perfectly doable.
Sure thing, the separation to two endpoints makes the API more clear, easier to debug and maintain the code. But besides being "restful" this can be treated as an opinionated claim.
I didn't really get the argument of integrating multiple APIs - in my understanding, the effort is the same, and even more clear to front-enders, but they might have their own arguments.
After coding for a couple of years, I have implemented many different software services into applications I was coding, using API documentation that software owner has provided. And I thought that was all about APIs I need to know, that it's just a way to make to software services communicate with each other.
But now I got a task to create an application, I wont go into detail, but let's say it just needs to implement CRUD operations and that it should use Vue on front and Laravel on back. And in the explanation of a task it is mentioned that I should use REST API for triggering those operations. And that's the part that confuses me!
Since I have never created an application from scratch, I was only working on already stable applications, fixing bugs and implementing new functionalities (and I guess this is the what it looks like for the most of the people who work in big companies today), and that's why I thought that those two frameworks (Vue and Laravel) have already implemented REST APIs since they can communicate between themselves.
Why am I specifically asked to use REST API to trigger those operations? Is there any way other than using an API to make front communicate with back (even I am using frameworks already)? If not, do they want me to create my REST API for communication and not use the one that is already provided by frameworks? I am confused, why did they mention to use REST API as if it wasn't default option, something that shouldn't even even be questionable, just an expected behavior.
why did they mention to use REST API as if it wasn't default option
For many years, offering an API in the backend for JS frontend consumption was not the default option. Traditional "round trip" applications use a form that submits to the server with a full page refresh, and I'd hazard a guess that most web applications live today still work like that.
With the advent of Vue, React, Angular etc, there is an expectation that fetching data and sending data is done via APIs in an AJAX operation. This gives applications a more seamless feel, and they're faster, since only a relatively small amount of data needs to be sent or received.
In small Laravel/Vue applications, the frontend and backend are often in the same repo, and are deployed together as a single unit. However, as the size and complexity of an application increases, there is value in splitting up these pieces into microservices, which can be deployed separately, without tricky system dependencies complicating the deployment pipeline and sign-off process. Using an API lends itself well to that approach.
Indeed, as the backend increases, the API is not one service, but several, split by process area (e.g. user, sign-up, checkout, dashboard, etc).
Do Laravel and Vue always use ... APIs to communicate?
So, to answer your main question, you don't have to use APIs/AJAX with Vue and Laravel. You can still use standard HTTP forms and redraw the whole screen if you want.
Do Laravel and Vue always use RESTful APIs to communicate? [my emphasis]
Another way of interpreting the question is that perhaps you have received instructions from someone who was differentiating a REST API from a different kind of API. On the web, GraphQL is becoming more popular. Server-to-server, SOAP (XML) used to be very common, and is still in use in many enterprises.
FOA, The gap is not going to fill "ASAP" because it requires domain knowledge that you are missing. And yes RESTful API is the best way unless you want multi-dimensional communication across multiple platforms.
I have a requirement to persist some data in a table (single table). The data is coming from UI. Do i need to write just the system API and persist the data OR i need to write process and system API both? I don't see a use of process API in this case. Please suggest. Is it always necessary to access system API through process API or system API can be invoked without process API as well.
I would recommend a fine-grained approach to this. We should be following it through the experience layer even though we do not have must customization to the data.
In short, an experience layer API and directly calling System layer API (if there is no orchestration/data conversion/formatting needed)
Why we need a system API & experience API? A couple of points.
System API should be more attached to the underlying system. And if
in case, in the future, it changes then it should not impact any of
the clients.
Secondly, giving an upper layer gives us the feasibility to add
different SLAs, policies, logging and lots more, to different
clients. Even if you have a single client right now it's better to
architect for the future. Reusing is the key advantage of these APIs.
Please check Pattern 2 in this document
That is a question for the enterprise architect in your organisation. In this case, the process API would probably be a simple proxy for the system API, but that might not always be the case in future. Also, it is sometimes useful to follow a standard architectural pattern even if it creates some spurious complexity in the implementation. As always, there are design trade-offs and the answer will depend on factors that cannot be known by people outside of your organisation.
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.
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.