Tag Info

New answers tagged

0

What is REST (in simple English) Plain English: REpresentation: the action of speaking or acting on behalf of someone. State Transfer: transfer status. Technical: we don't transfer an actual object but a representation of it in some form (eg a html table to represent a database table).courtesy REST is not a specific web service but a design ...


1

I believe 403 is wrong, because 403 is for situations where you aren't getting access to the resource, and there is no way whatsoever to get access. For your customers, there is obviously a way to get access: Pay up. 401 is truly wrong, because not only are you using it for authentication, but that is what it is there for. Since you are writing an API, I ...


0

WebDAV uses HTTP 507 Insufficient Storage for this and includes an additional error code for quota exceeded in the request body, to distinguish it from other kinds of storage limitations.


3

I think 403 is the only reasonable response, though 405 Method Not Allowed or 409 Conflict might be acceptable, I don't think either are as good as 403 which states: The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server ...


0

REST affects a single resource, it does not mean you can only update a single property on that resource. Some RESTful interfaces (eg SMTP) have a single property putting system, where you repeatedly call a custom verb with a single property until your resource is fully populated with all your data. Others send a blob of data in a single packet (XML, query ...


0

Stick to the fundies; they are fundamental for a reason. <scheme>://<user>:<password>@<server.tld>:<port>/path;parameter?query#fragment (note that the usage of user:password to identify userinfo is deprecated and is a generally bad practice. They are included for completeness' sake as they are still technically valid segments ...


1

You have stated your choice that pets have a globally unique id. This means that a pet can be transferred to another owner without changing the pet's id (generally a good thing for stability under db refactoring). Further, it means that should you want to, you can have two owners (e.g. a couple or roommates, etc..) for the pet. (Not to mention directly ...


2

If a pet only exists in the context of a user, then it makes sense to make pet a subresource of user. But if you can envision the pet as a standalone resource as well, then it would be intuitive to put it on its own path. Ideally, you would structure your resources the way you think about them.


0

I think this: Should you write your back-end as an API? is a verry good summary of your thoughts. Thanks to gbjbaanb for this answer!! The benefits of writing the backend as an API from beginning will save much time in later development process. Another point are the security reasons. Two systems are much better than one. The next thing is, that one team ...


2

Since you are updating just part of the resource you should consider using PATCH HTTP method. Request format depends on your other API calls. Prefer consistency. If you use JSON elsewhere use JSON. Same goes for XML or whatever language you use. I suggest using JSON, but I don't know how complex your API is. Do, I'd do this: PATCH person/1 Content-Type: ...


2

You are being squeezed in both directions, with tricky input and a tricky back-end. In an ideal world, you'd challenge some of these constraints, but I get the impression you won't get anywhere. The algorithm you describe sounds like your only option, although I think it can be improved on a little. Call listTransactions and store all transactions in a ...


3

I cannot be sure that each CSV file has only been processed once... You might want to attempt to solve your question by handling this first. If I am getting this right, the crux of your problem doesn't appear to be individual duplicate transactions (since you mentioned "I know for sure that there are no duplicate records in each CSV file"), but to ...


2

Considering you stated that it is about REST API, think that each call to the API will result in some network traffic, where latency and transfer time apply. So I would say the less calls to the API you make (store results in memory to search through), the better. However, when you work with the API, you don't always have a choice: if the API itself is not ...


0

Introducing an extra service tier always have a cost in complexity and performance overhead. There are some specific kinds of architecture where introducing a shared service tier (like a REST API) may improve perforce due to shared caching - but it sounds like it is not the kind of architecture you have. Consider an architecture where you have multiple web ...


1

You are right, there is no clear benefit to introduce a REST API layer between a web app and a database, and it has a cost in complexity and performance overhead. The reason you are getting contradictory answers is confusion about what is the 'client' in your architecture. In your architecture (if I understand it correct), you have browsers interacting ...


3

1) It's typically best to be explicit about the display of your rested resources. Thus, it makes sense to follow the collection/:id/sub-collection/:id paradigm with your API. 2) It's considered an anti-pattern in the REST world to use anything other than nouns for your collections in your URIs. That's because REST best practices expect your "verbiage" to ...


0

It depends. Obviously, the more layers in your code the slower it goes. But... there comes a point where direct end-to-end performance doesn't matter as much as scalability. If you have 1 user accessing your database on a local PC, it can go fast. If you have a thousand users accessing the same DB on the same PC, chances are you're going to see them all ...


0

If find it hard to answer this question. The correct general answer should be: it depends. The way I see it with REST: 1. You make an object in your code to call the REST method 2. Call http method 3. Code inside your REST API queries the database 4. Database returns some data 5. REST API code packs up the data into Json and sends it t your client 6. ...


2

If you're concern is speed, then yes a Rest service will be slower for the reasons stated above. However, speed of the type you describe is rarely the primary concern and if it is, can be addressed in other ways. Premature optimisation is the root of all evil. Consider if your primary concern is interoperability (mobile, web, B2B), now REST is very ...


8

When you add complexity the code will run slower. Introducing a REST service if it's not required will slow the execution down as the system is doing more. Abstracting the database is good practice. If you're worried about speed you could look into caching the data in memory so that the database doesn't need to be touched to handle the request. Before ...


0

I don't know where you get lost, but it is pretty clear, when you're using REST API you are doing extra step, and extra step "always" mean slower when programming involved. There's pros and cons, but if you can access database directly from your application it always better to call it directly instead of using Web API, of course if you use Web API you can ...


2

There are two methods for running a standard site (non-RESTful) in parallel with a RESTful service. The website consumes the RESTful service. This would often mean you are creating a one page app (Angular, etc). This is simplest from the backend standpoint in that you should have minimal additional coding on the backend, but you need to create an entire ...


0

If the data will be consumed by something else, either a frontend UI or another application somewhere else on the Internet, then you need a REST API. Otherwise, you don't.


0

If it's a batch operation, I'd rather process all the operations one by one, and return the array of objects with their own status. You can return the HTTP status code 200 OK if all the operations succeeded, or a 207 Multi-Status if you have operations that failed amongst your batch.


0

There is the question whether 202 is the right result for what you are doing, and the other question is how the client processes it. If a client receives a 202, chances are that it doesn't handle it properly (many clients will only recognise 200 as success, everything else is bad). But what if the client recognises it: 202 means the server promised to do ...


4

There are two similar responses that should be considered depending on what the expected response should be. The 202 Accepted response is a "yep, got that" response. The resource is created and the server will get around to doing something with that. The request has been accepted for processing, but the processing has not been completed. The request ...


6

202 Accepted The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. Seems like a good fit to me. That the resource gets created immediately does not actually complete the processing in your case.


0

Both [{"author": "Dan Brown", "isbn": "123456", "title": "Digital Fortress"},{"author": "JK Rowling", "isbn": "234567", "title": "Harry Potter and the Chamber of Secrets"}] and { "list": [{"author": "Dan Brown", "isbn": "123456", "title": "Digital Fortress"}, {"author": "JK Rowling", "isbn": "234567", "title": "Harry Potter and the Chamber ...


3

The reason you make your response JSON compliant is that JSON is a defacto standard; any language with a JSON parser can trivially parse it, and if you're using JavaScript, you don't even need a parser since JavaScript understands it natively. In other words, make it JSON compliant, and you won't have to write your own parser. Further, there will be no ...


6

Your post should be a single, self contained action that succeeds as a whole or fails as a whole. Therefore if one item contains an error you should reject the entire set. You should also be checking these items if at all possible before even starting your database transaction so you have the chance to error out early. Of course, if your database engine ...


0

I presume you are talking about guesstimating urls, that is, replacing my "/4/" with a "/42/" to see if someone else has something under http://www.mypage.com/questions/42/answers". As far as I know the first and foremost best practice is to implement proper security everywhere, so that a user who does not have permission to see something will never be able ...


1

If your primary concern is preventing user X from accessing a resource A that's unique to user Y, then per-user ids don't solve this. What you really need is authentication, i.e. a secure way of verifying that a request for resource A is actually being made by user Y, not just some other user pretending to by Y. If you don't have authentication, then ...


0

As far as I can tell, there's no reason to be concerned about a field like completedOn. Can you say more specifically about what concerns you? It would help us to understand your concerns if you could provide an example of an implementation that you think is more correct. There are some downsides to determining the time stamp on the client in my view, ...


0

A lot of people have allready talked about what REST means, etc etc. But none seem to address the real issue: your design. Why is grandparent different from a father? they both have children that can possibly have children that can ... Eventually, they are all 'human'. You probably have that in your code as well. So use that: GET ...


0

It sounds like you have a tree structure. And the search criteria just decides which node of the tree should be used as a root node where the search for children should start. I would create the service based on that. What you want to get from the service are children that match the text. GET /myservice/api/v1/children?search={text} but there are other ...


6

First As Per RFC 3986 §3.4 (Uniform Resource Identifiers § (Syntax Components)|Query 3.4 Query The query component contains non-hierarchical data that, along with data in the path component (Section 3.3), serves to identify a resource within the scope of the URI's scheme and naming authority (if any). Query components are for ...


2

Short answer: you can't. If it is on the client there is no way you can avoid this scenario if the 'attacker' is dedicated. There is simply no way you can 'force' your application to talk only to your server as the user can intercept and tamper with the communication, forcing it to other servers and returning canned responses. You could make it harder for ...



Top 50 recent answers are included