Hot answers tagged

15

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 ...


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 ...


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 ...


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 ...


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 ...


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. ...


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 ...


2

If the server creates tasks on its own, without a trigger from the user, and the user retrieves those tasks at some later time, then it would be proper to retrieve the complete list of tasks with GET /tasks/ or, to get the tasks after you last checked GET /tasks/?created_after=20160331 If, on the other hand, the server creates a new task in response to ...


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 ...


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 ...


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 ...


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 ...


1

Note: I am not a restafarian. I'm stubbornly pragmatic about things so if you are looking for the dogmatic 'true' REST answer, you might not get it from me. The very simple answer to your question is that the OPTIONS verb is meant to be used to describe the methods that are available at a given resource. However this isn't universally accepted. ...


1

I can recommend you to use swagger.io to define a contract. The used Open API approach is held general so you keep as universal as possible with your backend. The swagger specs are machine readable and the swagger tool-chain is very comfortable for both sides on client side and server side. You can also put the definition file under version control of your ...


1

Basically, one key point in REST architectural style is the self-descriptive message aspect. What you call "contract", i call it content type (or media type). If both client and server agree on the content type (i.e. content negotiation), they agree on the semantics on the message. For example with xHTML content type, a client know that a <p> ...



Only top voted, non community-wiki answers of a minimum length are eligible