New answers tagged

0

TL;DR latency is unpredicatable in general. Start with investigating worst case. If REST host goes down, a call will only return after TCP timeout (configurable, defaults can reach 10 minutes). To prevent this ensure, you have adequate timeouts set on client's side and be ready to handle failures. Latency also depends on distance, hardware, software and ...


0

The only reason to introduce a rest service (besides it being fun and interesting) it to allow multiple computers to access the functionality. This alone can be enough to determine that it is a good idea. For performance: going to the network and back is slow. Think of the difference between having a file in memory and on disk. One is much faster than ...


1

Here's a problem with your proposed approach. If you send the requests over HTTP, a 3rd-party can snoop the traffic and pick out the authorization token. Then they could send their own requests to the end-point using the token. Solution: use HTTPS rather than HTTP when doing the initial authorization to obtain the token, and whenever you use the token. ...


1

For the first question, your approach seems correct to me. You consume a token in the sendsms entry that can only be generated by the login endpoint. You could also use a generic token created by login, and not easily guessable (it would be equivalent to a cryptographically generated session ID), used as primary key to a database tuple. There you can store ...


1

One of the core design goals of Websockets is that it allows both HTTP and Websocket protocols to be communicated over the same port. It achieves this by explicitly requiring a client to perform a Websocket handshake with an HTTP Upgrade request. In this way the server can handle a standard HTTP request connection as well as an HTTP Upgrade request that is ...


3

The POST /documents/<documentId>/revisions endpoint has to also modify the DocumentDrafts table to reflect the fact that the document is now in a "clean" state and can be modified by another user Different layer. It is important to understand that it is usually not desirable to tightly couple the API layer to the service and/or data layers. ...


0

We ended up implementing the "Windows Service" scenario knowing that it would not scale but intending to build a scalable solution when we have to. With the current implementation a Web Job runs a console application that queries the DB for all notification definitions, runs appropriate queries and sends e-mails. It is easy to test (just run the console app) ...


0

Can you expand on what you mean by dynamically add properties? I take it that you need to do this while code is running, rather than simply edit the source files? If so maybe check out named tuples as part of the Python collections module https://docs.python.org/2/library/collections.html You can create a class dynamically like this EmployeeRecord = ...


2

If I'm following correctly you are considering using an API that only provides a dumb interface into your data, ie you can't query through the API you can only request all the data in one go. So if you want to look up the Product for one user you have to fetch all, lets say, 20 million products and on the client side filter through them for the ones that ...


1

The obvious alternative to all this -- which functions, but defeats one purpose of status codes -- would be to always include the metadata: This is the correct way to go. The state a resources is in with regard to domain specific log (aka business logic) is a matter for the content type of the resource's representation. There are two difference ...


1

HTTP Status Code for Resource not yet available suggests returning a 409 conflict response, rather than a 404 response, in the case that a resource doesn't exist because it is in the middle of being generated. From the w3 spec: 10.4.10 409 Conflict The request could not be completed due to a conflict with the current state of the resource. This ...


1

After a lot of back and forth and discussions with colleagues i have settled with option 2. Here is why: The strategies are equal functionality-wise. The race conditions are what causes trouble. We anticipate these race conditions to occur: Multiple devices of the same entity initially request a token [in a very small timespan] Multiple devices of the ...


16

HTTP 202 Accepted (HTTP/1.1) You are looking for HTTP 202 Accepted status. See RFC 2616: The request has been accepted for processing, but the processing has not been completed. HTTP 102 Processing (WebDAV) RFC 2518 suggests using HTTP 102 Processing: The 102 (Processing) status code is an interim response used to inform the client that the ...


3

If you want to ease load on your servers where the webservices providing REST endpoints live, there is no other way than to introduce caching to these servers. You could specify a constraint that a client would have to introduce cache in his application so he does not hit your services that often, but how are you going to guarantee that is really going to ...


1

You said: Now, the difficulty is: each time we would have to know about a user products, we would need to send a request to the API to get the products names and other data, since we would only save its Id internally. This is okay in this simple example, but there will be cases much more complex than this (Reports, for instance) and it just ...


0

What I did was use self.__dict__.update(json) which copies items in the JSON dict into the object's dict and so they appear as properties of the object. The client can then use dot notation to access or mutate them.


4

No. REST has to do with working with resources over the Internet; LocalHost doesn't really qualify as such, unless perhaps you're running a web server on LocalHost. Google Volley is a client-side library. It can potentially connect to RESTful resources, but it, in and of itself, does not make something RESTful. If you simulated a RESTful resource on ...


0

You make me feel old :-) IBM MQSeries was originally launched in 1992, and was primarily used on mainframe based systems. Java 1.0 was not released until 1996. I promise you that your application is not too old to talk to messaging systems. It may be that they don't wish to couple to a messaging system, but there is no way it is "too old". I have ...


0

If you wish to permit the user to override your normal error handling, you can consider returning a 200 SUCCESS status with additional information in extended HTTP headers. For example, you could return X-APP-STATUS: 422 Unprocessable entity X-APP-SOURCE: Invalid ID 'fo0' This would give your client-side code the information necessary to either warn the ...


0

There are no warning result codes in http, you either return a success (200) or an error (400, 500). The only thing I know of that could be analogous to what you want is something like code 401 'unauthorised' - which is an outright failure, but causes most clients to automatically re-attempt connection with credentials. For a REST API you need to tell the ...


0

To anyone interested, on Android you CAN verify that the request you have gotten was sent from your app. In short, when you upload your app to google you sign it, with a unique key that known only to you (and google). The verification process goes(ish) like this: your app goes to google and ask for auth token your app sends the token securely to your ...


3

200 OK Always returning "200 OK" is a terrible practice. It really kills anyone trying to write a client against the API. REST client frameworks rely on accurate status codes and will break if they receive "200 OK" even when it's not OK. The author of the REST client will have to jump through hoops to make it work correctly. As a case study, I was recently ...


7

Best to map onto what semantics you are trying to convey. /api/organization/:orgId/users/:userId This reads to me as there being a bunch of organizations, and for each organization, you have a bunch of users, and you want to get information for that user. /api/users/:userId?organizationId=orgId This reads to me as there being a bunch of users, and each ...


1

Here is how MVC is intended to work... The controller receives the request from the client, performs any business rules logic to determine and implement the changes to the model that are required. The final part is that it selects the appropriate model and view to return to the client. The View defines the presentation of the model to the client. I have a ...



Top 50 recent answers are included