Tag Info

New answers tagged

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

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


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


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


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


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


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


0

The following is more RESTfull because every grandparentID gets it own URL. This way the resource gets identified in a unique way. GET /myservice/api/v1/grandparents/{grandparentID} GET /myservice/api/v1/grandparents/{grandparentID}/parents/children?search={text} The query parameter search is a good way to execute a search from the context of that ...


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

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

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


0

I find the practices described here to be helpful: What about actions that don't fit into the world of CRUD operations? This is where things can get fuzzy. There are a number of approaches: Restructure the action to appear like a field of a resource. This works if the action doesn't take parameters. For example an activate action could be mapped to a ...


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


0

In this situation, I always think of the interface first, then write PHP code to support it. It's a REST API, so meaningful HTTP status codes are a must. You want consistent, flexible data structures being sent to and from the client. Let's think of all the things that could go wrong and their HTTP status codes: The server throws an error (500) ...


-2

I was facing something similar, I did 3 things, Created a ExceptionHandler for myself called ABCException. Since I am using Java & Spring, I defined it as public class ABCException extends Exception { private String errorMessage; private HttpStatus statusCode; public ABCException(String errorMessage,HttpStatus statusCode){ ...


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


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


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


0

A combination of using GIT release branches (or fork each version into a separate repository) to support and maintain old API versions and possibly have some re-usable code that can be shared as a dependency, like a commons library, is most likely the way to go. So each API version would be a separately deployable artifact. This allows flexibility so that, ...


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


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



Top 50 recent answers are included