Tag Info

New answers tagged

0

These three options are not mutually exclusive, you can use an combination of both client-side and server-side caches. However some of data, like comments, may become stale, if kept in cache for too long. Considering you can't check whether that is the case, you should probably refrain from storing it at all. On the other hand content usually doesn't change ...


0

I would (almost) discount option 3. Choosing between 1 and 2 depends on two things: (A) how big the result of a single, total fetch is (B) how much of the detail of the result the client/user will typically use in that session. It's easy to make a decision if A and B are extremes: If A is large and B is small, definitely go for option 1 (A la Carte). ...


4

Hypermedia never really got popular with REST-like APIs - to the point that when an API actually implements hypermedia navigation, the term RESTful simply isn't enough to distinguish it from any other "RESTful" web APIs. REST has become an catch-all term or any resource-based web APIs and new names like Hypermedia API have been coined to focus on ...


1

You can call it a Web API. It's a very broad term but it can avoid nitpicking about meaning of other API type definitions. The term is less technical and precise compared to alternatives like HTTP API, but that might be an advantage when talking to non-technical people. This term is also used by Leonard Richardson (who defined the Richardson Maturity Model ...


1

You can call it whatever you like, people tend to (almost religiously) latch onto any part of the REST 'spec' that you're not following and use that as a point of protest which is highly detrimental to the development. But that said, the simple fact is that there are (nearly) zero services exist that implement true REST for their API serves. In our team we ...


30

Call it an HTTP API. It conforms to HTTP standards, and doesn't have anything else layered on top (e.g. SOAP). The HTTP standards define resources, verbs, headers, content negotiation, etc. REST (REpresentational State Transfer) is an architecture with requirements that happen to be amenable to existing HTTP standards, but HTTP works on all its own. ...


17

Richardson Maturity Models goes like this POST everywhere. A single endpoint. (SOAP) POST everywhere. Multiple endpoints. (resources) HTTP VERBS. Multiple endpoints. Like 2 and returns links to resources. (RESTful) So according to the model I would call it a webservice conforming to richardson level 2 or something along those lines. ...


2

It is a CRUD interface (Create, Read, Update, Delete) over HTTP. I can't think of any authorities to back it up this assertion, so I hope you get more and better answers.


3

According to the documentation, anonymous information about the user's system is sent with an update request. I'd say that technically your colleagues are correct. This info doesn't appear to be used to affect the response to the request, so it doesn't really belong there. A better way to send that info would probably be to POST to a separate resource, ...


3

RFC 7231, Section 4.3.1: A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request. So in short, sending a payload is indeed incorrect. As far as REST goes, use POST if you're creating an item, and PATCH for partial updates or PUT for full ...


1

It's all about discovery: the ability of your API to be understandable and usable by the next developer encountering it. If the WebSocket methods are easily discoverable, and it is clear that they should be used in conjunction with the ordinary REST methods, then your design is probably sound. In practice, for this discovery to occur, I think your ...


0

If you do not own the REST API's, your responsibility ends with them You need tests that check if your application calls the API under your control correctly. Therefore, use the actual application with the actual service (the one you control) but calling mocked services (the ones you don't control). So... Use canned data for the services you don't ...


0

You need to store the API token in your sever and need to validate it in database for each API call , So when u need to revoke access , remove the API token from the database , so it will invalid during next call


1

A resource is a resource. The resource doesn't change simply because the permissions change. What you can do with the resource or what you can know about the resource might change, but the mapping of the resource doesn't change. If it does it becomes a different resource type. So in your description, it's conceivable that various properties would exist at ...


1

I can see some sensible answers to this question already, but I thought I would expand and offer my opinion. You've described a system that appears to couple logic into large classes, and be tightly coupled across many different functions. The first way to try and refactor this is to first ensure you understand what a 'good' architecture/codebase would ...


1

Of course, I never saw your actual code, but from what you've said, I would propose something close to the following architecture. I'm sorry for pseudo-code, I just wanted it to be fast & clear ;) UI layer: dataService = new DataService(); dataService->makeDataRequest(requestName, requestParams[], cachedDataArrivedCallback, ...


0

I'd go for more logical grouping, Imagine a system where hotel bookings are performed, where there are 2 different hotel reservation API (A and B) and one payment gateway. In this sort of situation few best practices to follow would be, Wrap any third party APIs into one of services (whenever third party API changes only the wrapper service is need to ...


-1

You are asking intelligent questions about refactoring. When single classes mix up different functionality, it gets hard to read and debug. Never mind the lengthy code. Sometimes a class can get large innocently, but mixing metaphors within the same class = bad List the methods in your class and separate out into different classes any utility type classes ...


2

As Frank said, you appear to have figured out a lot of this on your own already, so I only have one piece of advice regarding the main question. Do the refactoring gradually, incrementally, alongside whatever changes you make to add business value. Don't try to break the 5000 LOC monster into five 1000 LOC critters all in one go. As long as you keep in mind ...


0

I would consolidate the actions and handlers into higher level abstractions that operate using a fixed order of operations. The priority-based solution will not scale.


4

Where we should put search action? In GET /search/:text. This will return a JSON array containing the matches, every match containing the album it belongs to. This makes sense, because the client may be interested not in the track itself, but the entire album (imagine that you are searching for a song which, you believe, was in the same album as the one ...


3

Should REST or the database be responsible for referential integrity? Both: DB should have proper constraints. API should have validation rules which reflect those constraints (e.g. "role_id cannot be null on user object"), check those, and provide meaningful error messages when they are violated. Is it bad practice to have foreign keys ...


0

Here is how we do it , am not sure if it's good or bad but is works so good. I too have an dedicated endpoint for sync /sync/{syncKey} As soon as the user authenticated , if the user client (mobile apps) want to have sync they can call add to sync API , ther I store one entry per device per user , and return the entry key as sync key Then whenever any ...


1

Yes, Rest API is very powerful for your scenario Expose all of your services through API endpoints. Always consider doing following when building Apis Authentication - have an strong authentication system in your API, like token based authentication ( Json web token) Authorization - every single API need to be access controlled, have the user ...



Top 50 recent answers are included