Tag Info

Hot answers tagged

4

The base HTTP standard does not mandate that there be a document returned with a response. For economy's sake, when an HTTP status conveys all that's required the body would be wasteful. However, there are standards built on top of HTTP that add new rules. There is an open JSON API standard that specifies: A JSON object MUST be at the root of every JSON ...


3

This is where you get it wrong: If my clients pass me an id reference In a REST systems, client should never be bothered with IDs. The only resource identifiers that the client should know about should be URIs. This is the principle of "uniform interface". Think about how clients would interact with your system. Say the user starts browsing through a ...


3

It depends. Basically, you have to look at what the expected latency of the connection is, what the bandwidth is, and what responsiveness you want. As an example: Suppose the round trip latency from client to server is 100 msecs and the bandwidth is 8 mb/s. If you send the "full" data is 2Mb and the "partial" data is 400kb, then it will take 350 msecs to ...


2

No but it will help for consistency of your code. It also good for debugging purposes. It will also a big help in the maintenance of the website. Remember this: Error code is for machine, Error message is for human. So I am suggesting for you to use a response body. Anyway, its negative effect is just minimal(just a few bytes sent over the network) compared ...


2

You may want to consider a Message Queuing service like Rabbit MQ, this would allow you to send data to a server that would simply keep hold of it until you had a consumer/worker available to process it. You would have to consider things like memory usage on the message queue server if your datasets are very large (or find a way to send the data in smaller ...


2

Authentication on APIs allows the server to verify that the client making the request has the authorization (i.e. privileges) to take whatever action the request encapsulates. Sticking to your Twitter example, direct messages are private to a user, so in order to allow access to them, Twitter must verify that the client has valid credentials for that user ...


2

404 means "the resource you asked for doesn't exist." It's up to the server to decide when that response is appropriate. Google has apparently interpreted it to mean "your API request was malformed." Other REST APIs might also interpret it to mean "your request was well-formed, but you are asking for something which does not exist." This is why you need ...


1

When dealing with HTTP status codes the level of abstraction to be thinking on is the context of the HTTP request that was just made. If your client makes a request GET http://example.com/someresource your client is saying Yo! example.com! Give me a representation of "someresource" If the client cannot do that then do not return 200 (OK). What ...


1

The "right" answer is dependent on your situation, but never link. POST { "name": "Batman", "groupId": 1 } is fine POST { "name": "Batman", "groupName": "my group" } Could be nice for convenience. Using a link is bad, because the link could change depending on tons of stuff (i.e. www.example.com/groups/1 or example.com/groups/1 or ...


1

there is problem in ur requirement gathering 1st u said "...(its the independent record) and then I can proceed with the person_id to create Phone,Email and Address" then u said : If the person creation succeeds but one or more preceding record creation fails then actually Employee creation fails" means it is not independent. lets assume its independent ...


1

B definitely sounds like the only sane choice. A means depending on implementation details of the REST API. It makes the "transaction" very fragile, breaks encapsulation, and other bad things. C I'm not entirely sure what you're saying you'll do with a QBWI (beyond the email to admin part), but it doesn't sound like an actual solution to the problem. ...


1

I'm not sure why people think putting the ID values in the URL means its somehow a REST API, REST is about handling verbs, passing resources. So if you want to PUT a new user, you'd have to send a fair chunk of data and a POST http request is ideal, so although you might send the key (eg. user id), you'll send the user data (eg name, address) as POST data. ...


1

What you suggest is the usual way to achieve this - the alternative is to directly communicate with the other devices in a per-to-peer topology, but that breaks down quickly as devices are added. So your requirement is to check and detect errors. You could implement a heartbeat to the server so you know its alive, and/or you can add a version number that ...


1

If you're asking does RavenDB (RavenHQ is just hosted RavenDB) work as persistent storage for any data system, including an API you write, of course it does. It's a document database. That's its job. I'm not exactly sure what you're asking, unless you are asking "what is RavenDB?" If so, I recommend reading through the marketing materials and documentation ...


1

It's perfectly valid, and is usually done in situations like the one you have. Others have suggested message queues, which are nice but they'll either take up memory or wind up writing the data to a backing store anyway, so now you've got another layer of software doing what you could do directly. That said, it may be easier and cleaner to use a message ...


1

The two approaches I've seen are as follows: Duplicate the dependency in a Development environment. This clearly requires more resources, and can be a hassle when it comes to keeping your environments in sync, but it's as representative of Production as you can get. All you have to change is the endpoint of your REST API dependency. Create a dependency ...


1

You can define the resources and representations in the way that suits your needs. I usually use GET to provide a "summary" view of a collection (like ".../followers") as a resource that provides a list of summaries of the followers, including their ids (or URIs if I'm being good). This is usually sufficient for the client to provide a list that the user can ...


1

I would suggest returning only what is needed + a little clarification. For example, depending on how your API is to be used, you could include a copy of the object, as is exists after being saved. So a POST of {key: 123} might return {key: 123, foo: 'bar'}. The basic idea is it is better to return the object then to have to query for it again. That ...


1

I would not return a simply success status in the response, the http error code only signals success or error. I'd only include use the response itself to add detailed error information such as application specific error codes or error messages. For PUT, PATCH and POST requests you typically return the state return the state of the resource after the ...



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