I had a use case that there is a server that can have n number of source. There can be several clients that can connect to this server and get the sources list and then can subscribe to the server to listen the source add, update and delete operation.
To implement this with REST principle, I have thought that first time when the client gets connected, the server gives the full source list along with the session id. Then with this session id, the client polls the url after a configured time interval and listen to the source updates.
The communication will looks like
Client>
GET: /Federation/Sources
Server>>
{"sessionId":xyz,"data":{"source1"...........}}
Client>
GET: /Federation/Sources/{sessionId}
Server>>
{"sessionId":xyz,"data":{"sourceadded"...........}}
Client>
PUT: /Federation/Sources/{sessionId}
{"data":{"Recieved"}}
This client call will then updates the server to remove the source correspond to this session id.
And then client poll continues with the session id.
Can expert please give their feedbacks or comments if this is a good approach or can there be any alternative good approach that can be follow with REST principle?
Instead of passing back id's for the client to use to build the URL, simply pass back the entire URL to the client. Perhaps with more information about what the URL is for. This is the HATEOAS part of REST.
Related
I am a bit confused by the terminology of REST APIs being stateless. For example, if we had a To-Do list API, and one of the endpoints was used to update or delete entries, then each request does not happen in isolation.
If I create an entry before someone else queries the total entries, then their response will depend on my response.
But, PUT is seen as a verb of REST APIs. Can someone help me clear my confusion?
Stateless means that you store the client state on the client and send it with each request instead of storing it on the server. The latter is the classical server side sessions, where you have a session cookie with the session id and the server stores the session data in the database or file system. This does not scale well for Facebook size applications, that's why they rather send the session data with each request. You can ensure that the session data is not modified by the client if you sign it with a private key stored on the server. So there is signature verification by each request, but still it is less expensive than maintaining session data for more than 1M users in a database and syncing it around the globe with multiple servers to solve the single point of failure problem too. They rather send the session data with each request and if it passes the verification, then the request is handled by any node chosen by the load balancer without touching the database to get session data.
As of the part of the question related to concurrent calls, it can be solved with resource versioning. You can send the actual ETag of the resource and use the if-match header with your PUT request so the server will be able to figure out which version you request is based on. If there is a newer version, then the ETag won't match and the server will reject the request. There can be other ways to solve concurrency, it always depends on your application how you handle it.
I have the following case: I have a REST API, that can only be accessed with credentials. I need the frontend to make requests directly to the API to get the data. Because I don't want to hide the credentials somewhere in the frontend, I set up a proxy server, which forwards my request with http://docs.guzzlephp.org/en/stable/index.html but adds the necessary authentication.
No that worked neatly for some time, but now I added a new view where I need to fetch from one more endpoint. (so far it was 3 requests locally (MAMP))
Whenever I add a fourth API request, which all are being executed right on page load, my local server crashes.
I assume it is linked to this topic here:
Guzzle async requests not really async?, specifically because I make a new request for every fetch.
First: Do you think that could be the case? Could my local server indeed crash, because I have only 3 (probably simultaneous) requests?
Second: How could I approach this problem.
I don't really see the possibility to group the requests, because they are just incoming to the proxy url and every call of the proxy url will create a new Guzzle client with its own request...
(I mean, how many things can a simple PHP server execute at the same time? And why would it not just add requests to the call stack and execute them in order?)
Thanks for any help on this issue.
How is possible to handle timeouts in time consuming operations in a REST API. Let's say we have the following scenario as example:
A client service sends a request to insert a resource through a REST API.
Timeout elapses. The client thinks the insertion failed.
REST API keep working and finishes the insertion.
Client do not notify the resource insertion and it status is "Failed".
I can think I a solution with a message broker to send orders to a queue and wait until they are solved.
Any other workaround?
EDIT 1:
POST-PUT Pattern as has been suggested in this thread.
A Message Broker (add more complexity to the system)
Callback or webhook. Pass in the request a return url that the server API can call to let the client know that the work is completed.
HTTP offers a set of properties for invoking certain methods. These are primarily safetiness, idempotency and cacheability. While the first one guarantees a client that no data is modified, the 2nd one gives a promise whether a request can be reissued in regards to connection issues and the client not knowing whether the initial request succeeded or not and only the response got lost mid way. PUT i.e. does provide such a property, i.e.
A simple POST request to "insert" some data does not have any of these properties. A server receiving a POST request furthermore processes the payload according to its own semantics. The client does not know beforehand whether a resource will be created or if the server just ignores the request. In case the server created a resource the server will inform the client via the Location HTTP response header pointing to the actual location the client can retrieve information from.
PUT is usually used only to "update" a resource, though according to the spec it can also be used in order to create a new resource if it does not yet exist. As with POST on a successful resource creation the PUT response should include such a Location HTTP response header to inform the client that a resource was created.
The POST-PUT-Creation pattern separates the creation of the URI from the actual persistence of the representation by first firing off POST requests to the server until a response is received containing a Location HTTP response header. This header is used in a PUT request to actually send the payload to the server. As PUT is idempotent the server simply can reissue the request until it receives a valid response from the server.
On sending the initial POST request to the server, a client can't be sure whether the request reached the server and only the response got lost, or the initial request didn't make it to the server. As the request is only used to create a new URI (without any content yet) the client may simply reissue the request and in worst case just create a new URI that points to nothing. The server may have a cleanup routine that frees unused URIs after a certain amount of time.
Once the client receives the URI, it simply can use PUT to reliably send data to the server. As long as the client didn't receive a valid response, it can just reissue the request over and over until it receives a response.
I therefore do not see the need to use a message-oriented middleware (MOM) using brokers and queues in order to guarantee reliable messaging.
You could also cache the data after a successful insertion with a previously exchanged request_id or something of that sort. But I believe message broker with some asynchronous task runner is a much better way to deal with the problem especially if your request thread is a scarce resource. What I mean by that is. If you are receiving a good amount of requests all the time. Then it is a good idea to keep your responses as quickly as possible so the workers will be available for any requests to come.
I am looking at options to log client id for every request (if available), so that it can be used for reporting purpose to find out the number of request per client. Ids logs the client id for token request when LogLevel is Information. Looking at IDS code, we need to extract the client id from AuthenticationHeader or from Body of the request. Wanted to know if there anything that is already built into ids to do this. Any other ways to do this?
Absolutely!
Implementing the IEventService is what you're after.
An overview of all the events being transmitted to the IEventService can be viewed in the source of these internal extension methods; IEventServiceExtensions.
The AccessTokenIssuedEvent, AuthorizationCodeDetails and RefreshTokenDetails events will include the ClientId receiving the token - so you can create an audit log.
The default implementation of IEventService is the DefaultEventService, which will use the logging mechanism you're using for IdentityServer, but you can swap that out to log to a DB if you prefer.
I'm implementing a CQRS system with Akka persistence and I'm trying to understand the request response bit of CQRS.
There are few answers on SO on how to send response back to client and this article also mentions a few good patterns. But instead of generalising using big words can someone please explain how should I send response back to the client in CQRS for the following simple use case.
Use case
Suppose the user is on a page which displays users profile which displays the following information
Username
Address
Phone number
And In my system I have one Actor per User which stores that user's profile information.
On the UI user wants to update the address and the following things happen:
User makes an AJAX REST call to update address of user
UpdateUserAddressCommand(address:String) generated
UpdateUserAddressEvent(address:String) generated
UserAddressUpdatedEvent(updatedAddress:String) generated (state of the UserActor updated)
Now how do I send back the full state of UserProfile in the system ? Since CQRS discourages sending response for a Command ?
With respect to the CQRS pattern, the REST layer can be considered a client of the system using CQRS, and therefore you may send a response (from the REST server to the web browser) without violating a "principle".
In your case, it's quite simple:
REST call to /api/endpoint/1234 -> REST server generates the command as above.
Server returns code "202 Accepted" and sets the Location: header to
something like /api/user/profile/1234
Client queries /api/user/profile/1234 to query the full state of the UserProfile.
You can combine 3. with HTTP long polling if you are using asynchronous query side updates/eventual consistency.