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 5 years ago.
Improve this question
I need to launch an application on a remote system from Java. I know the IP address and the location of the executable batch file on the remote system. I am trying to get it done with PSExec but I can't seem to get it to work due to domain issues.
One suggestion was to use REST API instead. I don't see any info on using REST to launch an application. So anyone who can tell me if this is possible?
REST is about resource state manipulation via their representations on the top of stateless communication between client and server. REST is an architectural style and it's protocol independent but, in practice, it's commonly implemented on the top of the HTTP protocol.
Can I use REST APIs to remotely launch an application?
If you can represent your application state as a resource, so you can probably create a REST API to manage it.
In practice, your server can provide a set of URLs to locate the resources and their state can be manipulated via HTTP verbs and representations such as JSON and/or XML.
HTTP headers can be used to exchange some metadata about the request and response while HTTP status code should be used to inform the client regarding the status of the operation.
Keep it stateless by storing all session context in the client.
Related
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 2 years ago.
Improve this question
I have been unable to get Tibco support to come up with a solution for this, so I am thinking it is not possible, even though they document that it is.
I want to:
deploy an input control to the JasperReports server,
putting it into a specific folder,
using Java and their REST API,
and then list all the input controls back through a HTTP request
(return a full list in json or xml)
Requirements:
Language: Java
API: JasperReports Server REST API
Authentication: POST
Then any HTTP method after the authentication via POST to send a JSON file to the server that defines and deploys the input control.
artifacts:
A single .java file (using built in JDK libraries, or minimal dependencies declared in a pom.xml)
pom.xml
To understand this, I am hoping to find a bare bones solution that uses low level HTTP calls (no frameworks other than any HTTP client in Java).
I have searched, read the manual (it's horrible), many documents, so many things, and logged a support ticket with Tibco, and they are unable to find anyone in the company that can do this.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
So RESTful APIs are stateless wherein the server does not store any state about the client session on the server side.
And consistent hashing in load balancing is used to associate a client with a server, ie, all requests from a given client will be directed to a given server only (amongst a group of servers) because that server has some data stored in it about that client.
So, if our server uses RESTful APIs then is there no need for consistent hashing while load balancing?
Not necessarily. While RESTful APIs are stateless, your server isn't. Server-side caching doesn't violate the constraints of REST. If a server is able to keep information from a client in its cache, it could make a significant difference if future requests are made to that server instead of to another one which may need to perform more work to retrieve the client's data.
It is very situational, however, so I can't speak to your specific server setup!
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
I have to create an application with a permanent connection (I need to send data update from the server) and, in parallel, I need to configure this app. My idea was to use Socket.IO for the connection and use it also for the configuration, with specifics event name.
But someone said that it's better to keep Socket.IO only for sending data from the server and use a REST API to configure the app.
I want to know if using a REST API along with of a Websocket connection is a good practice or not, and if no, why.
You always can provide a REST API along with a WebSocket API for different purposes. It's up to your requirements and it depends on what you want to achieve.
For instance, you can use a WebSocket API to provide real-time notifications while the REST API can be used to manage resources.
There are a few details you should be aware of:
REST is a protocol-independent architectural style frequently implemented over the HTTP protocol and it's meant to be stateless.
In HTTP, the communication is driven by the client: the client requests and the server responds.
WebSocket is a bi-directional, full-duplex and persistent connection protocol, hence it's stateful.
In WebSockets, once the communication is established, both client and server can exchange frames in no particular order.
Just to mention one example of application that provides different APIs: Stack Exchange provides a REST API along with a WebSocket API.
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 6 years ago.
Improve this question
I have an html5 webapp that fetches data using jquery from rest java api. I have two questions:
How can I encrypt data on server and decrypt it locally with different key for each user. Where can I store this key in client side? Does it needed, or it is just enough to secure the rest service call with some authentication method?
Is there any standard way to prevent other rest clients (except browsers) to hit this rest api?
use HTTPS
Use authentication so you know who is hitting it - oauth, client certificates, session token - but there's nothing you can really do to prevent anything other than a browser accessing it. You could make it harder by rapidly recycling the authentication token using javascript (but this will break in horrible ways if the user opens more than one window).
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.