I have an android app which communicates with server through REST calls. OAuth is used for authentication. Everything plays well, with signpost library and AsyncTasks.
Since AsyncTask has many flaws (memory leaks etc.), I was trying to implement REST calls with
RoboSpice library. RoboSpice is very cool. The only problem (and also a showstopper for me) is
that I can not figure out how does OAuth fit in with RoboSpice.
btw, I'm using robospice with spring-android.
I am one of the maintainers of RS. Personally, I never used OAuth with Spring Android. I only use the REST part os Spring Android.
So, I don't have any idea of what could be missing. Would you mind to give more details on what's blocking you ?
Normally, it should be pretty easy to inject anything into a RS service.
Related
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 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.
Evenin' good people!
I'm creating a virtual whiteboard application for my third year project at university. The system uses a Flex front-end and a Spring/BlazeDS back-end. I'd say that I'm pretty new to BlazeDS and to Flex, so apologies if anything I say doesn't make a lot of sense.
I'm attempting to implement a (reasonably) secure server push from Spring/BlazeDS to the Flex application, based on groups (whiteboards).
I've discovered that BlazeDS offers a publish/subscribe messaging architecure which includes support for sub-groups. However, I can't find a way of restricting access to particular (password-protected) groups, available only to users pre-authenticated with the system. my system is also using a custom log-in process, mediated through Flex RPC calls.
Additionally, I've considered writing a custom messaging-adapter; however getting this to #autowire with the rest of my project (and a custom authentication system) has proven difficult, and so far I've had little success.
All-in-all, I'm at a little bit of a loss for how to continue. Any help would be greatly appreciated.
If I understand your problem currectly you are trying to implement ' Authorization based subscriptions'. The user can subscribe to a group only if he is authorized to so?
If so, Flex has a concept of 'subtopics' the client subscribes on to a destination with this subtopic. This subscription can be manually managed by extending Adapters in flex. override a couple of methods to do so.
when the client requests for subscribe on this 'subtopic', handle the subscription in the adapter, maintain a list of subscriptions, also there is an overriden method in the same adapter to handle the push of the messages, you can use it to find the authorization of the user and push messages accordingly. (these methods are not invoked by you directly) thre are classes in blazeds to construct the message objects and pushe it to the client i think it is AsyncMessage use this to push.
Its been a long time since I worked on this, I hope you got some direction.
I would like to implement OpenAuth in a Windows application. I am currently embedding a browser inside the application, but this solution sucks.
Is there a way to do this using raw APIs?
Since you mention a browser, I assume you are interested in implementing an OAuth client, not a provider. You can try the Scribe library. It's written in Java, has client implementations for several different providers and is pretty easy to extend for new providers.
How can I call a webmethod of one application from another application, when both are developed in C#?
You can't do this, of course. It would be a huge security hole.
As suggested by your tag, it would be necessary for the developer of an application to explicitly expose to the world the methods he wants to be called from other applications. This could be done through WCF, or possibly through COM.
Alternatively, the code to be called caould be placed into a class library, and referenced by both projects.
Expose the method through SOAP or REST or COM or (going old-school) CORBA or ...
Be prepared that doing this is a massive increase in the complexity of the applications. You start to have to worry properly about security, and about how all the pieces interact, and many other issues. There's a lot of depth here, far too much for a simple answer.
This can be done using WCF instead of webservice