Разработка/Тестирование приложений Твиттера, не хлопая API
Я предполагаю, что правильно сформированный XML ниже. Я добавил корневой узел с именем root:
<?xml version="1.0" encoding="UTF-8"?>
<root>
<ShipmentStop>
<StopSequence>1</StopSequence>
<LocationRef>
<LocationGid>
<Gid>
<Xid>LOCATION 1</Xid>
</Gid>
</LocationGid>
</LocationRef>
<ArrivalTime>
<EventTime>
<EstimatedTime>
<Date>20181128070000</Date>
</EstimatedTime>
</EventTime>
</ArrivalTime>
</ShipmentStop>
<ShipmentStop>
<StopSequence>2</StopSequence>
<LocationRef>
<LocationGid>
<Gid>
<Xid>LOCATION 2</Xid>
</Gid>
</LocationGid>
</LocationRef>
<ArrivalTime>
<EventTime>
<EstimatedTime>
<Date>20181129070000</Date>
</EstimatedTime>
</EventTime>
</ArrivalTime>
</ShipmentStop>
</root>
В вашем исходном xpath вы использовали
ShipmentStop[/LocationRef/LocationGid/Gid/Xid='LOCATION 1'
or /LocationRef/LocationGid/Gid/Xid='LOCATION 2'][1]
Обратите внимание на использование / в /LocationRef. Когда вы делаете это, вы ищете из корневого узла вашего XML, таким образом, он потерпит неудачу. Чтобы использовать узел контекста, просто добавьте точку перед косой чертой, например,
ShipmentStop[./LocationRef/LocationGid/Gid/Xid='LOCATION 1'
or ./LocationRef/LocationGid/Gid/Xid='LOCATION 2'][1]
, или вы можете удалить ./ в xpath. Например:
ShipmentStop[LocationRef/LocationGid/Gid/Xid='LOCATION 1'
or LocationRef/LocationGid/Gid/Xid='LOCATION 2'][1]
, поскольку LocationRef является дочерним узлом узла ShipmentStop.
4 ответа
I would probably start by mocking the specific parts of the API you need for your application. In fact, this may actually force you to come up with a cleaner design for your app, because it more or less requires you to think about your application in terms of "what" it should do rather than "how" it should do it.
For example, if you are using the Twitter Search API, your application most likely should not care whether or not you are using the JSON or the Atom format option. The ability to search Twitter using a given query and get results back represents the functionality you want, so you should mock the API at that level of abstraction. The output format is just an implementation detail.
By mocking the API in terms of functionality instead of in terms of low-level implementation details, you can ensure that the application does what you expect it to do, before you actually connect to Twitter for real. At that point, you've already verified that the app works as intended, so the only thing left is to write the code to make the REST requests and parse the responses, which should be fairly straightforward, so you probably won't end up hitting Twitter with a lot of junk data at that point.
Caching is probably the best solution. Besides that, I believe the API is limited to 100 requests per hour. So maybe make a function that keeps counting each request and as it gets close to 100, it says, OK, every 10 API requests I will pull data. It wouldn't be hard set, probably a gradient function that curbs off when you are nearing the limit.
Я использовал Tweet #, он кэширует и должен делать все, что вам нужно, поскольку он покрывает 100% API твиттера, а затем немного ...
http://dimebrain.com /2009/01/introduction-tweet-the-complete-fluent-c-library-for-twitter.html
Cache stuff in a database... If the cache is too old then request the latest data via the API.
Also think about getting your application account white-listed, it will allow you to have a 20,000 api request limit per hour vs the measly 100 (which is made for a user not an application).